This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Store LLT instead of uint64_t in MachineMemOperand
ClosedPublic

Authored by arsenm on May 20 2021, 1:34 PM.

Details

Summary

GlobalISel is relying on regular MachineMemOperands to track all of
the memory properties of accesses. Just the raw byte size is
insufficent to disambiguate all situations. For example, if we need to
split an unaligned extending load, we need to know the number of bits
in the original source value and can't infer it from the result
type. This is also a problem for extending vector loads.

This does decrease the maximum representable size from the full
uint64_t bytes to a maximum of 16-bits. No in tree testcases hit this,
other than places using UINT64_MAX for unknown sizes. This may be an
issue for G_MEMCPY and co., although they can just use unknown size
for large static sizes. This also has potential for backend abuse by
relying on the type when it really shouldn't be relevant after
selection.

This does not include the necessary MIR printer/parser changes to
represent this.

Diff Detail

Event Timeline

arsenm created this revision.May 20 2021, 1:34 PM
arsenm requested review of this revision.May 20 2021, 1:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 20 2021, 1:34 PM
Herald added a subscriber: wdng. · View Herald Transcript
arsenm updated this revision to Diff 346852.May 20 2021, 2:11 PM

Pass through in IRTranslator

There are a number of other getMachineMemOperand methods - is the intention to add LLT variants of those as well? And deprecate the uint64_t Size variants?

There are a number of other getMachineMemOperand methods - is the intention to add LLT variants of those as well? And deprecate the uint64_t Size variants?

Yes, faithfully preserving the memory type everywhere will take additional changes. It should only be semantically significant for G_* operations, so arguably we could keep the uint64_t versions around

Are we already testing the G_MEMCPY path with large (invalid) sizes?

Anyone else got any comments?

llvm/lib/CodeGen/MachineOperand.cpp
1044

Do we need to handle s > maxsize ?

Are we already testing the G_MEMCPY path with large (invalid) sizes?

Anyone else got any comments?

I'm not aware of anything that actually uses the MMOs on G_MEMCPY.

arsenm added a comment.Jun 1 2021, 9:46 AM

Anyone have any syntactic feedback before I push through the test updates?

RKSimon accepted this revision.Jun 1 2021, 12:50 PM

My only remaining comment is whether we should strive to deprecate the raw size variants.

Anyone else?

This revision is now accepted and ready to land.Jun 1 2021, 12:50 PM
aemerson accepted this revision.Jun 1 2021, 3:27 PM
arsenm updated this revision to Diff 350733.Jun 8 2021, 4:15 PM

Add some more helper overloads