[PATCH] D102552: [GlobalOpt] recompute alignments for loads and stores of updated globals

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D102552#2763262 <https://reviews.llvm.org/D102552#2763262>, @spatel wrote:

> In D102552#2761398 <https://reviews.llvm.org/D102552#2761398>, @lebedev.ri wrote:
>
>>> The problem is that if we have an alignment that's known better than the minimum (and that alignment is correct, not UB, for the original code), it may not hold for the new inner type (see inline test comment).
>>
>> That's precisely my point. Isn't it a bug that we reduce the alignment? Shouldn't we instead overalign the split-off scalar to the maximal non-UB alignment requested by the uses?
>
> I don't think it is possible to overalign the global / base pointer to make this work. For example, take the motivating case:
>
>   @a = global [2 x [7 x i32*]] align 16
>
> Assume 32-bit alignment for each pointer element in that array. We have (7 + 1) * 4 = 32-bytes ahead of the 8th element, so the original access to element [1][1] is guaranteed to be "align 16" bytes.
> Now we strip off the outer array specifier:
>
>   @a0 = global [7 x i32*] align ??
>
> What over-alignment of the base pointer can we use to make the access of element [1] of this new array continue to have "align 16"?
> Do we want to use padding to make this work? Not sure how to specify that.

Thank you for spelling this out.
Indeed, if we want to align an offset element, then we indeed need padding.
I'm conflicted here.


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

https://reviews.llvm.org/D102552