<div dir="ltr">Ok, how do i reproduce the problem you're seeing? For me:<div><br></div><div><div>% ./bin/opt -S -O2 < test-fca.ll</div><div>; ModuleID = '<stdin>'</div><div>target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"</div><div>target triple = "x86_64-unknown-linux-gnu"</div><div><br></div><div>declare void @foo()</div><div><br></div><div>define void @test({ i8, i8 }* nocapture) {</div><div>brancher.exit:</div><div>  %v.sroa.0.0.dst.sroa_idx = getelementptr inbounds { i8, i8 }* %0, i64 0, i32 0</div><div>  store i8 1, i8* %v.sroa.0.0.dst.sroa_idx, align 1</div><div>  %v.sroa.2.0.dst.sroa_idx = getelementptr inbounds { i8, i8 }* %0, i64 0, i32 1</div><div>  store i8 2, i8* %v.sroa.2.0.dst.sroa_idx, align 1</div><div>  tail call void @foo()</div><div>  ret void</div><div>}</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 2, 2015 at 3:40 PM, Björn Steinbrink <span dir="ltr"><<a href="mailto:bsteinbr@gmail.com" target="_blank">bsteinbr@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 <a href="tel:2015.01.02%2023" value="+12015010223">2015.01.02 23</a>:29:00 +0100, Björn Steinbrink wrote:<br>
> [Added llvm-commit back to Cc, sorry, removing it wasn't intentional]<br>
><br>
> On <a href="tel:2015.01.02%2014" value="+12015010214">2015.01.02 14</a>:05:28 -0800, Chandler Carruth wrote:<br>
> > On Fri, Jan 2, 2015 at 2:02 PM, Björn Steinbrink <<a href="mailto:bsteinbr@gmail.com">bsteinbr@gmail.com</a>> wrote:<br>
> ><br>
> > > 2015-01-02 22:36 GMT+01:00 Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>>:<br>
> > > ><br>
> > > > On Fri, Jan 2, 2015 at 1:27 PM, Björn Steinbrink <<a href="mailto:bsteinbr@gmail.com">bsteinbr@gmail.com</a>> wrote:<br>
> > > >><br>
> > > >> If we have a simple load through a GEP that is fed by a store of an<br>
> > > >> aggregate, we can use the GEP indices to walk the stored aggregate and<br>
> > > >> extract the appropriate value to replace the load.<br>
> > > ><br>
> > > ><br>
> > > > What's the motivation for this change?<br>
> > ><br>
> > > The rust compiler hit a case where not having this optimization caused<br>
> > > a branch not to be removed. The corresponding issue for rustc is<br>
> > > <a href="https://github.com/rust-lang/rust/issues/20149" target="_blank">https://github.com/rust-lang/rust/issues/20149</a><br>
> > ><br>
> > > > Note that SROA replaces all stores of aggregates with scalar stores of<br>
> > > > the components specifically so that neither it nor GVN needs to<br>
> > > > cope with aggregate loads or stores.<br>
> > ><br>
> > > SROA did the opposite thing in this case, replacing individual stores<br>
> > > insertvalues and a store of an FCA. I'm attaching the full output of<br>
> > > opt -print-after-all -O2 -S for the failing test case given in the<br>
> > > rust issue. The first SROA creates the FCA store, and later when the<br>
> > > call to `unwrap` is inlined the existing optimizations can't eliminate<br>
> > > the branch that comes with it, because of the FCA store.<br>
> ><br>
> ><br>
> > SROA doesn't create FCA stores in any cases I'm aware of... Can you provide<br>
> > a somewhat reduced test case rather than a massive log?<br>
><br>
> I got myself confused because it introduced the insertvalue<br>
> instructions. The FCA store was already present and not constructed by<br>
> SROA. I've attach a small test case this time.<br>
<br>
</div></div>And... I forgot it again :-/ I'm really sorry, apparently this is not my<br>
day.<br>
<span class="HOEnZb"><font color="#888888"><br>
Björn<br>
</font></span></blockquote></div><br></div>