[LLVMdev] ARMLoadStoreOptimizer bug

[David Meyer]

Evan,

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.

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.

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).

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.

- pdox


On Mon, Feb 6, 2012 at 11:15 PM, Evan Cheng <evan.cheng at apple.com> wrote:

> 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).
>
> Evan
>
> On 2012 2 4, at 09:46, David Meyer <pdox at google.com> wrote:
>
> > Evan & llvmdev,
> >
> > 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.
> >
> > But here's what I'm seeing in the debug output:
> >
> > # Before ARMLoadStoreOptimizer:
> > BB#21: derived from LLVM BB %cond.end
> >     Live Ins: %LR %R0 %R1 %R7 %R10 %R11
> >     Predecessors according to CFG: BB#14 BB#18
> >         STRi12 %R7<kill>, %R1, 0, pred:14, pred:%noreg;
> mem:ST4[%first257](tbaa=!"int")
> >         %R1<def> = ADDri %R1<kill>, 4, pred:14, pred:%noreg,
> opt:%CPSR<def>
> >         Bcc <BB#23>, pred:0, pred:%CPSR<kill>
> >         B <BB#22>
> >     Successors according to CFG: BB#23 BB#22
> >
> > # After ARMLoadStoreOptimizer:
> > BB#21: derived from LLVM BB %cond.end
> >     Live Ins: %LR %R0 %R1 %R7 %R10 %R11
> >     Predecessors according to CFG: BB#14 BB#18
> >         %R1<def> = STR_POST_IMM %R7<kill>, %R1, %noreg, 4, pred:14,
> pred:%noreg
> >         Bcc <BB#23>, pred:0, pred:%CPSR<kill>
> >         B <BB#22>
> >     Successors according to CFG: BB#23 BB#22
> >
> > 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.
> >
> > - pdox
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120207/aa5f608d/attachment.html>