1717
1818#include " dxc/DXIL/DxilConstants.h"
1919#include " dxc/DXIL/DxilModule.h"
20+ #include " dxc/DXIL/DxilOperations.h"
2021#include " dxc/DXIL/DxilResourceBase.h"
2122#include " dxc/DxilPIXPasses/DxilPIXPasses.h"
2223#include " llvm/ADT/STLExtras.h"
@@ -597,23 +598,27 @@ bool DxilDbgValueToDbgDeclare::runOnModule(llvm::Module &M) {
597598
598599 auto &Functions = M.getFunctionList ();
599600 for (auto &fn : Functions) {
600- // #DSLTodo: We probably need to merge the list of variables for each export
601- // into one set so that WinPIX shader debugging can follow a thread through
602- // any function within a given module. (Unless PIX chooses to launch a new
603- // debugging session whenever control passes from one function to another.)
604- // For now, it's sufficient to treat each exported function as having
605- // completely separate variables by clearing this member:
601+ llvm::SmallPtrSet<Value *, 16 > RayQueryHandles;
602+ PIXPassHelpers::FindRayQueryHandlesForFunction (&fn, RayQueryHandles);
603+ // #DSLTodo: We probably need to merge the list of variables for each
604+ // export into one set so that WinPIX shader debugging can follow a
605+ // thread through any function within a given module. (Unless PIX
606+ // chooses to launch a new debugging session whenever control passes
607+ // from one function to another.) For now, it's sufficient to treat each
608+ // exported function as having completely separate variables by clearing
609+ // this member:
606610 m_Registers.clear ();
607- // Note: they key problem here is variables in common functions called by
608- // multiple exported functions. The DILocalVariables in the common function
609- // will be exactly the same objects no matter which export called the common
610- // function, so the instrumentation here gets a bit confused that the same
611- // variable is present in two functions and ends up pointing one function
612- // to allocas in another function. (This is easy to repro: comment out the
613- // above clear(), and run PixTest::PixStructAnnotation_Lib_DualRaygen.)
614- // Not sure what the right path forward is: might be that we have to tag
615- // m_Registers with the exported function, and maybe write out a function
616- // identifier during debug instrumentation...
611+ // Note: they key problem here is variables in common functions called
612+ // by multiple exported functions. The DILocalVariables in the common
613+ // function will be exactly the same objects no matter which export
614+ // called the common function, so the instrumentation here gets a bit
615+ // confused that the same variable is present in two functions and ends
616+ // up pointing one function to allocas in another function. (This is
617+ // easy to repro: comment out the above clear(), and run
618+ // PixTest::PixStructAnnotation_Lib_DualRaygen.) Not sure what the right
619+ // path forward is: might be that we have to tag m_Registers with the
620+ // exported function, and maybe write out a function identifier during
621+ // debug instrumentation...
617622 auto &blocks = fn.getBasicBlockList ();
618623 if (!blocks.empty ()) {
619624 for (auto &block : blocks) {
@@ -640,9 +645,8 @@ bool DxilDbgValueToDbgDeclare::runOnModule(llvm::Module &M) {
640645 if (auto *DbgValue =
641646 llvm::dyn_cast<llvm::DbgValueInst>(instruction)) {
642647 llvm::Value *V = DbgValue->getValue ();
643- if (PIXPassHelpers::IsAllocateRayQueryInstruction (V)) {
648+ if (RayQueryHandles. count (V) != 0 )
644649 continue ;
645- }
646650 Changed = true ;
647651 handleDbgValue (M, DbgValue);
648652 DbgValue->eraseFromParent ();
@@ -809,8 +813,8 @@ static llvm::DIType *FindStructMemberTypeAtOffset(llvm::DICompositeType *Ty,
809813 }
810814 }
811815
812- // Structure resources are expected to fail this (they have no real meaning in
813- // storage)
816+ // Structure resources are expected to fail this (they have no real
817+ // meaning in storage)
814818 if (SortedMembers.size () == 1 ) {
815819 switch (SortedMembers.begin ()->second ->getTag ()) {
816820 case llvm::dwarf::DW_TAG_structure_type:
@@ -907,8 +911,9 @@ void DxilDbgValueToDbgDeclare::handleDbgValue(llvm::Module &M,
907911 }
908912
909913 // Members' "base type" is actually the containing aggregate's type.
910- // To find the actual type of the variable, we must descend the container's
911- // type hierarchy to find the type at the expected offset/size.
914+ // To find the actual type of the variable, we must descend the
915+ // container's type hierarchy to find the type at the expected
916+ // offset/size.
912917 if (auto *DerivedTy = llvm::dyn_cast<llvm::DIDerivedType>(Ty)) {
913918 const llvm::DITypeIdentifierMap EmptyMap;
914919 switch (DerivedTy->getTag ()) {
@@ -961,10 +966,10 @@ void DxilDbgValueToDbgDeclare::handleDbgValue(llvm::Module &M,
961966
962967 auto *Zero = B.getInt32 (0 );
963968
964- // Now traverse a list of pairs {Scalar Value, InitialOffset + Offset}.
965- // InitialOffset is the offset from DbgValue's expression (i.e., the
966- // offset from the Variable's start), and Offset is the Scalar Value's
967- // packed offset from DbgValue's value.
969+ // Now traverse a list of pairs {Scalar Value, InitialOffset +
970+ // Offset}. InitialOffset is the offset from DbgValue's expression
971+ // (i.e., the offset from the Variable's start), and Offset is the
972+ // Scalar Value's packed offset from DbgValue's value.
968973 for (const ValueAndOffset &VO : SplitValue (V, InitialOffset, B)) {
969974
970975 OffsetInBits AlignedOffset;
@@ -1022,11 +1027,11 @@ bool DxilDbgValueToDbgDeclare::handleStoreIfDestIsGlobal(
10221027 llvm::dyn_cast<llvm::GetElementPtrInst>(asInstr.Get ())) {
10231028 // We are only interested in the case of basic types within an array
10241029 // because the PIX debug instrumentation operates at that level.
1025- // Aggregate members will have been descended through to produce their
1026- // own entries in the GlobalStorageMap.
1027- // Consequently, we're only interested in the GEP's index into the
1028- // array. Any deeper indexing in the GEP will be for embedded
1029- // aggregates. The three operands in such a GEP mean:
1030+ // Aggregate members will have been descended through to produce
1031+ // their own entries in the GlobalStorageMap. Consequently, we're
1032+ // only interested in the GEP's index into the array. Any deeper
1033+ // indexing in the GEP will be for embedded aggregates. The three
1034+ // operands in such a GEP mean:
10301035 // 0 = the pointer
10311036 // 1 = dereference the pointer (expected to be constant int zero)
10321037 // 2 = the index into the array
@@ -1035,7 +1040,8 @@ bool DxilDbgValueToDbgDeclare::handleStoreIfDestIsGlobal(
10351040 llvm::dyn_cast<ConstantInt>(asGEP->getOperand (1 ))
10361041 ->getLimitedValue () == 0 ) {
10371042 // TODO: The case where this index is not a constant int
1038- // (Needs changes to the allocas generated elsewhere in this pass.)
1043+ // (Needs changes to the allocas generated elsewhere in this
1044+ // pass.)
10391045 if (auto *arrayIndexAsConstInt =
10401046 llvm::dyn_cast<ConstantInt>(asGEP->getOperand (2 ))) {
10411047 int MemberIndex = arrayIndexAsConstInt->getLimitedValue ();
@@ -1120,9 +1126,9 @@ VariableRegisters::VariableRegisters(
11201126 PopulateAllocaMap (Ty);
11211127 m_Offsets.AlignTo (Ty); // For padding.
11221128
1123- // (min16* types can occupy 16 or 32 bits depending on whether or not they are
1124- // natively supported. If non-native, the alignment will be 32, but the
1125- // claimed size will still be 16, hence the "max" here)
1129+ // (min16* types can occupy 16 or 32 bits depending on whether or not they
1130+ // are natively supported. If non-native, the alignment will be 32, but
1131+ // the claimed size will still be 16, hence the "max" here)
11261132 assert (m_Offsets.GetCurrentAlignedOffset () ==
11271133 std::max<uint64_t >(DITypePeelTypeAlias (Ty)->getSizeInBits (),
11281134 DITypePeelTypeAlias (Ty)->getAlignInBits ()));
0 commit comments