[Validation] Drill through chained GEPs for TGSM

[llvm-beanz]

DXIL requires that TGSM pointers originate from a global variable in address space 3, and that any use of a pointer resolve to one and only one possible global variable.

In SM 6.9 with the introduction of native vectors to DXIL it is now possible to end up with a chain of GEP and/or bitcast instructions in the access chain for a TGSM pointer. To address this the validator needs to be able to walk up a TGSM chain to find the one unambiguous global.

Fixes #8571

Assisted by Claude Opus 4.7

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[V-FEXrt]

some/path/lib/DxilValidation/DxilValidation.cpp:3314:24: error: no member named 'getOperand' in 'llvm::Value'
 3314 |             Ptr = Ptr->getOperand(0);

Looks like that change doesn't work because Value doesn't have a getOperand. I think casting to Instruction here should be good enough?

[llvm-beanz]

Looks like that change doesn't work because Value doesn't have a getOperand. I think casting to Instruction here should be good enough?

Sorry, moving too fast on things. You can't cast these to Instructions because they are in the Operator class hierarchy not Instruction.

[alsepkow]

Did you mean 'access chain' in the description? Not change?

[Icohedron]

What if the phi or select is choosing between multiple GEPs or bitcasts that all point to the same global variable, just at different offsets? Would this still be valid DXIL?

[llvm-beanz]

I think it should be... but to be honest I can't even contrive how it would be possible to generate it from HLSL. Generating PHIs and selects on offsets is easy enough because you can just mess with the index, but the base address of an array isn't something HLSL allows you to conditionalize on.

[llvm-beanz]

Did you mean 'access chain' in the description? Not change?

🤦