<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 25, 2012 at 7:20 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank" class="cremed">eli.friedman@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 class="HOEnZb"><div class="h5">On Tue, Sep 25, 2012 at 7:00 PM, Nick Lewycky <<a href="mailto:nlewycky@google.com" class="cremed">nlewycky@google.com</a>> wrote:<br>
> On 25 September 2012 18:10, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" class="cremed">eli.friedman@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Sep 25, 2012 at 3:46 PM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca" class="cremed">nicholas@mxc.ca</a>> wrote:<br>
>> > Author: nicholas<br>
>> > Date: Tue Sep 25 17:46:21 2012<br>
>> > New Revision: 164641<br>
>> ><br>
>> > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=164641&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?rev=164641&view=rev</a><br>
>> > Log:<br>
>> > Don't drop the alignment on a memcpy intrinsic when producing a store.<br>
>> > This is<br>
>> > only a missed optimization opportunity if the store is over-aligned, but<br>
>> > a<br>
>> > miscompile if the store's new type has a higher natural alignment than<br>
>> > the<br>
>> > memcpy did. Fixes PR13920!<br>
>> ><br>
>> > Modified:<br>
>> > llvm/trunk/lib/Transforms/Scalar/SROA.cpp<br>
>> > llvm/trunk/test/Transforms/SROA/basictest.ll<br>
>> ><br>
>> > Modified: llvm/trunk/lib/Transforms/Scalar/SROA.cpp<br>
>> > URL:<br>
>> > <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/SROA.cpp?rev=164641&r1=164640&r2=164641&view=diff" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/SROA.cpp?rev=164641&r1=164640&r2=164641&view=diff</a><br>
>> ><br>
>> > ==============================================================================<br>
>> > --- llvm/trunk/lib/Transforms/Scalar/SROA.cpp (original)<br>
>> > +++ llvm/trunk/lib/Transforms/Scalar/SROA.cpp Tue Sep 25 17:46:21 2012<br>
>> > @@ -2272,8 +2272,9 @@<br>
>> > getName(".insert"));<br>
>> > }<br>
>> ><br>
>> > - Value *Store = IRB.CreateStore(Src, DstPtr, II.isVolatile());<br>
>> > - (void)Store;<br>
>> > + StoreInst *Store = cast<StoreInst>(IRB.CreateStore(Src, DstPtr,<br>
>> > +<br>
>> > II.isVolatile()));<br>
>> > + Store->setAlignment(II.getAlignment());<br>
>><br>
>> This isn't quite right: "0" alignment on a store has a different<br>
>> meaning from "0" alignment on a memcpy.<br>
><br>
><br>
> Well spotted, I was not aware of the difference! However, I looked at<br>
> LangRef and I disagree with your analysis:<br>
><br>
> store: "A value of 0 or an omitted "align" argument means that the operation<br>
> has the preferential alignment for the target."<br>
><br>
> memcpy: "If the call to this intrinsic has an alignment value that is not 0<br>
> or 1, then the caller guarantees that both the source and destination<br>
> pointers are aligned to that boundary."<br>
><br>
> So transforming zero to zero is fine as they both mean preferred alignment.<br>
<br>
</div></div>I'm not sure how you got here: if the alignment value is 0 or 1 for<br>
memcpy, the caller makes no alignment guarantees (per the section you<br>
quoted).<br>
<br>
<br>
Anyway, I just discovered there's another more serious issue with your<br>
commit: you aren't taking into account the offset between the original<br>
memcpy and the generated store. This is causing a failure on the<br>
bullet benchmark from the testsuite on 32-bit x86. I'm getting output<br>
like the following for stores expanded from a memcpy:<br></blockquote><div><br></div><div>Yea, this is just the tip of the iceberg here. I'm sorry about this, it slipped through my own review and my reviewers: the SROA pass completely ignored alignment on loads and stores it is synthesizing. =/ For example, there are loads just a bit above this that are still misaligned. I would just disable it, but I'm most of the way through fixing this, and should commit the fix momentarily. I'll also do a MinAlign computation here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[...]<br>
%groundTransform.sroa.0.0.tmp.i.i.i.i43.i.i.idx = getelementptr<br>
inbounds %struct.btDefaultMotionState* %tmp53, i32 0, i32 1, i32 0,<br>
i32 0, i32 0, i32 0, i32 0, i32 0<br>
store float 1.000000e+00, float*<br>
%groundTransform.sroa.0.0.tmp.i.i.i.i43.i.i.idx, align 16<br>
%groundTransform.sroa.1.4.tmp.i.i.i.i43.i.i.idx120 = getelementptr<br>
inbounds %struct.btDefaultMotionState* %tmp53, i32 0, i32 1, i32 0,<br>
i32 0, i32 0, i32 0, i32 0, i32 1<br>
store float 0.000000e+00, float*<br>
%groundTransform.sroa.1.4.tmp.i.i.i.i43.i.i.idx120, align 16<br>
%groundTransform.sroa.2.8.tmp.i.i.i.i43.i.i.idx123 = getelementptr<br>
inbounds %struct.btDefaultMotionState* %tmp53, i32 0, i32 1, i32 0,<br>
i32 0, i32 0, i32 0, i32 0, i32 2<br>
store float 0.000000e+00, float*<br>
%groundTransform.sroa.2.8.tmp.i.i.i.i43.i.i.idx123, align 16<br>
[...]<br>
<div class="HOEnZb"><div class="h5"><br>
-Eli<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>