<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 4:03 PM, Thomas Jablin <span dir="ltr"><<a href="mailto:tjablin@gmail.com" target="_blank">tjablin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div>I think this patch might not be the right approach. The underlying issue is that clang translates:<br><br>
union U { long m0[3]; long double m1; };<br><br></div>to:<br><br>%union.U = type { x86_fp80, [16 x i8] }<br>
<br></div>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?</div></blockquote><div><br></div><div>The type doesn't matter. The IR using the type matters.</div>
<div><br></div><div>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.</div>
</div></div></div>