[PATCH] SROA: Handle a case of store size being smaller than allocation size

Chandler Carruth chandlerc at google.com
Thu Aug 21 16:44:33 PDT 2014


On Thu, Aug 21, 2014 at 4:03 PM, Thomas Jablin <tjablin at gmail.com> wrote:

> I think this patch might not be the right approach. The underlying issue
> is that clang translates:
>
> union U { long m0[3]; long double m1; };
>
> to:
>
> %union.U = type { x86_fp80, [16 x i8] }
>
> The x86_fp80 type is 10 bytes of data aligned to 16 bytes. Is it
> permissible to copy only the lower 10 bytes of an x86_fp80?
>

The type doesn't matter. The IR using the type matters.

If you look at the IR that initially caused the bug, it doesn't copy the
x86_fp80, it uses a memcpy (*without* any metadata that would drop padding
bytes) to copy all of the bytes, and that's totally OK in the IR. But SROA
then switches to a load and store of the x86_fp80 incorrectly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140821/9644e7f8/attachment.html>


More information about the llvm-commits mailing list