Evan,<div><br></div><div>A test case is extremely hard to pin down. For months now, we've noticed our stage 2 LLVM ARM build has sporadic failures. Tests would start failing, then start working, then start failing, etc, for no apparent reason.</div>
<div><br></div><div>The test case I have (llc.bc, which is all of llc in bitcode form, 44.8 MB), only works against r149814. And in this case, there are only 2 cases of the miscompile occurring in the 93 MB .s file. I cannot reproduce the failure in ToT LLVM using the same bitcode file, or any other bitcode I have. All it takes is a slight bit of code change for the schedule to completely change, and suddenly the problematic instruction sequence no longer exists.</div>
<div><br></div><div>And even if I give you this bitcode file, you won't be able to run it to evaluate its functionality, because this bitcode file is targeting OS=NativeClient. (and it uses a private syscall interface that only works inside the NaCl environment in a particular context).</div>
<div><br></div><div>Do any public LLVM buildbots (internal or external) do a full three-stage ARM build? We do a two stage build, followed by rebuilding our entire system/universe.</div><div><br></div><div>- pdox</div><div>
<br></div><div><br><div class="gmail_quote">On Mon, Feb 6, 2012 at 11:15 PM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've committed a fix: r149970. Please try it. I would really appreciate it if you can provide us with a test case (unreduced test case is fine).<br>
<span class="HOEnZb"><font color="#888888"><br>
Evan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 2012 2 4, at 09:46, David Meyer <<a href="mailto:pdox@google.com">pdox@google.com</a>> wrote:<br>
<br>
> Evan & llvmdev,<br>
><br>
> I'm seeing a case where ARM Load/Store optimizer is breaking code. I have not had any luck trying to come up with a minimal example; it is breaking in our stage 2 LLVM build.<br>
><br>
> But here's what I'm seeing in the debug output:<br>
><br>
> # Before ARMLoadStoreOptimizer:<br>
> BB#21: derived from LLVM BB %cond.end<br>
>     Live Ins: %LR %R0 %R1 %R7 %R10 %R11<br>
>     Predecessors according to CFG: BB#14 BB#18<br>
>         STRi12 %R7<kill>, %R1, 0, pred:14, pred:%noreg; mem:ST4[%first257](tbaa=!"int")<br>
>         %R1<def> = ADDri %R1<kill>, 4, pred:14, pred:%noreg, opt:%CPSR<def><br>
>         Bcc <BB#23>, pred:0, pred:%CPSR<kill><br>
>         B <BB#22><br>
>     Successors according to CFG: BB#23 BB#22<br>
><br>
> # After ARMLoadStoreOptimizer:<br>
> BB#21: derived from LLVM BB %cond.end<br>
>     Live Ins: %LR %R0 %R1 %R7 %R10 %R11<br>
>     Predecessors according to CFG: BB#14 BB#18<br>
>         %R1<def> = STR_POST_IMM %R7<kill>, %R1, %noreg, 4, pred:14, pred:%noreg<br>
>         Bcc <BB#23>, pred:0, pred:%CPSR<kill><br>
>         B <BB#22><br>
>     Successors according to CFG: BB#23 BB#22<br>
><br>
> It appears that the ARM Load/Store optimizer has rolled the ADDri and STRi12 into the STR_POST_IMM, but has ignored the fact that ADDri sets CPSR (which is used by the following Bcc), whereas STR_POST_IMM does not set CPSR.<br>

><br>
> - pdox<br>
<br>
</div></div></blockquote></div><br></div>