[PATCH] D123991: [LangRef] Clarify load/store of non-byte-sized types

[Nuno Lopes via Phabricator via llvm-commits]

nlopes added a comment.

In D123991#3464417 <https://reviews.llvm.org/D123991#3464417>, @nikic wrote:

> In D123991#3464364 <https://reviews.llvm.org/D123991#3464364>, @nlopes wrote:
>
>> Well, here we are discussing the semantics of LLVM IR. It's ok for the semantics of SDAG to be different, as long as it's a refinement of LLVM IR's.
>> Padding at IR level is not observable normally. So we can define it as poison.
>>
>> The only way to observe padding is through store/load of different types. But we specify that the location of padding is non-deterministic in the case of vectors. I don't see a reason for padding in integer types to be different.
>>
>> The SDAG can happily assume that the padding is zero because stores at SDAG level enforce that. But we don't need to offer that semantics at IR level.
>>
>> The only advantage of defining padding as zero would be, as the examples show, fold load+zext into a larger load. But for this to work we would need to define the memory layout, and I don't know if that's consistent across backends. And is it worth it?
>
> I don't think the SDAG semantics would be a refinement of the IR semantics though. In SDAG, a non-byte-size load performs an implicit assert that the padding bits are zero, while the IR semantics (as specified here) would allow that padding to be poison. Presumably this is where the "the result is undefined if the value was not originally written using a store of the same type" wording that LangRef uses right now comes from, as that allows making a consistent choice between load and store.

But the SDAG stores will pad with zeros. So any load will see those zeros.
The SDAG semantics are a refinement, They do the optimization of assuming that padding bits are zero because of its store semantics. So I think we are fine.


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

https://reviews.llvm.org/D123991