This is an archive of the discontinued LLVM Phabricator instance.

Modify DXILPrepare to emit no-op bitcasts
ClosedPublic

Authored by beanz on Mar 22 2022, 4:16 PM.

Details

Summary

In supporting opaque pointers we need to re-materialize typed pointers
in bitcode emission. Because of how the value-enumerator pre-allocates
types and instructions we need to insert some no-op bitcasts in the
places that we'll need bitcasts for the pointer types.

Diff Detail

Event Timeline

beanz created this revision.Mar 22 2022, 4:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 4:16 PM
beanz requested review of this revision.Mar 22 2022, 4:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 4:16 PM
beanz updated this revision to Diff 418049.Mar 24 2022, 2:31 PM

Updateing DXIL-prepare to rely on dxil::TypedPointerType, and to properly handle function types.

beanz updated this revision to Diff 422941.Apr 14 2022, 12:53 PM

Rebasing on updated patches from earlier in the stack.

python3kgae added inline comments.Apr 14 2022, 11:32 PM
llvm/lib/Target/DirectX/DXILPrepare.cpp
141

Why bitcasts need to be at top of the block?
Could there be phi at top of the block?

154

Cannot find the check for only have one type.
Does it hide in PointerTypes.find ?

155–160

Could we have shouldOmit function and createNoOpBitcast function? The same code happened 3 times.

beanz added inline comments.Apr 15 2022, 7:34 AM
llvm/lib/Target/DirectX/DXILPrepare.cpp
141

Good point. I will adjust.

154

That comment isn't great. The pointer analysis assigns one type to each value based on how it is used. If the type of the user and the type assigned by pointer analysis match, we don't need a bitcast because the value will be assigned that type. If they don't match, we need a bitcast so that the user gets the correct typed pointer.

beanz added inline comments.Apr 15 2022, 7:52 AM
llvm/lib/Target/DirectX/DXILPrepare.cpp
155–160

The code here is actually not the same in all three places. The first two are super similar except that Inst is different types in both cases. The third is different because the interfaces for GEP instructions aren't the same.

beanz updated this revision to Diff 425265.Apr 26 2022, 10:53 AM

Updates based on PR feedback.

beanz updated this revision to Diff 425266.Apr 26 2022, 10:54 AM

Fixing a code comment.

kuhar added inline comments.May 8 2022, 6:57 PM
llvm/lib/Target/DirectX/DXILPrepare.cpp
105–106

nit: If you want to revisit this in a future patch, I think you can use enum_seq here: https://llvm.org/doxygen/Sequence_8h.html

113

I know this is existing code, but a tiny nit: I think the coding style prefers the end value to be calculated only once, e.g., for (size_t i = 0, e = size(); i != e; ++i) ...

127

nit: missing . at the end of the comment

133

Since I is a reference, it cannot be null, so we should use plain dyn_cast.
Second, the type on the left should be auto *.
Last, could we give it a more descriptive name since we know the type? Maybe Load or LI.

134

nit: missing . at the end of the comment

135–136

It is shadowed by other iterator variables below. Can we give it a more descriptive/unique name?

151

same here

152

also here

168

same here

169

also here

170–179

This pattern seems pretty repetitive: for each type, we check if the pointer operand is in the type, adjust the inter point, and emit a bitcast. Could we move it to a generic helper function? Something like:

if (Value *Bitcast = createNoopBitcast(Inst, Inst->getPointerOperand(), Inst->getPointerOperandType()) {
  // Update or replace Inst.
  continue;
}
kuhar added inline comments.May 8 2022, 7:03 PM
llvm/test/CodeGen/DirectX/omit-bitcast-insert.ll
26

I think it would be also worth having some tests where we do insert bitcasts for geps.

beanz updated this revision to Diff 428127.May 9 2022, 10:27 AM
beanz marked 10 inline comments as done.

Updating based on PR feedback. Thank's @kuhar!

kuhar accepted this revision.May 9 2022, 10:35 AM
This revision is now accepted and ready to land.May 9 2022, 10:35 AM
This revision was landed with ongoing or failed builds.May 9 2022, 11:41 AM
This revision was automatically updated to reflect the committed changes.