[PATCH] D85199: GlobalISel: Add generic instructions for memory intrinsics

Konstantin Schwarz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 13 07:20:58 PDT 2020


kschwarz added a comment.

In D85199#2210127 <https://reviews.llvm.org/D85199#2210127>, @arsenm wrote:

> In D85199#2193484 <https://reviews.llvm.org/D85199#2193484>, @arsenm wrote:
>
>> In D85199#2193321 <https://reviews.llvm.org/D85199#2193321>, @kschwarz wrote:
>>
>>> 
>>
>>
>>
>>> The problem we have is that some LLVM-IR passes introduce calls to `llvm.memcpy.p0i8.p0i8.i64`, even though our native pointer size is 32-bits. Since it turned out that fixing this in LLVM is quite invasive, we currently work around this problem by truncating the size argument to 32-bits before calling createMemLibcall.
>>
>> You would have to deal with this whether passes introduce this IR or not, unless we make it a verifier error to deviate from the pointer size (which would be inconsistent with every other pointer sized integer operand, although I think this is pointless)
>
> I'm thinking the IRTranslator should be responsible for this clamp, and the machine verifier should enforce the size of the length type. I'm not sure why we don't do this for G_INTTOPTR/G_PTRTOINT; I feel like the fact these aren't required to match the pointer size is a holdover from when the DataLayout was optional

Having the IRTranslator perform the clamp would solve the problem for us, and then the verifier can also enforce the property, as you said. We have a similar rule in our LegalizerInfo for G_INTTOPTR/G_PTRTOINT to clamp to our pointer size. Again making this a verifier error could simplify our rules.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85199/new/

https://reviews.llvm.org/D85199



More information about the llvm-commits mailing list