[llvm] r215862 - ARM: improve RTABI 4.2 conformance on Linux

[Saleem Abdulrasool]

On Wed, Aug 20, 2014 at 9:59 AM, Moritz Roth <moritz.roth at arm.com> wrote:

> The few failures I looked at in detail actually weren't using 64-bit
> integers. From what I've seen in gdb the function call to
> __aeabi_idivmod is fine as well, the problem seems to be in how the
> results are handled.
>

Yeah, the function calls looked fine to me as well.


> E.g. in the code I sent yesterday, only the quotient (r0) is
> saved to a stack slot, the register that has the remainder (r1) is
> simply overwritten, and any further references to that remainder are
> treated as if it was the same as the quotient (i.e. loading from that
> spill slot).
>
> Assembly (working):
>         movs    r7, #31
>         (...)
>         mov     r0, r4
>         mov     r1, r7
>         bl      __aeabi_idiv
>         str     r0, [sp, #32]           @ 4-byte Spill [of the quotient]
>         mov     r0, r4
>         mov     r1, r7
>         bl      __modsi3
>         str     r0, [sp, #24]           @ 4-byte Spill [of the remainder]
>         (...)
>
> Code after r215862:
>         movs    r1, #31
>         (...)
>         bl      __aeabi_idivmod
>         str     r0, [sp, #32]           @ 4-byte Spill [just the quotient?]
>

Hmm, somehow I missed that when I glanced at the asm output you sent out
earlier.  That area does look incorrect.  You said that this same code
works for -eabi targets?

        @DEBUG_VALUE: simulate:rem <- [SP+32]  ; both refer to the same
>         @DEBUG_VALUE: simulate:quot <- [SP+32] ; spill slot...
>         cmp     r4, #1
>         bge     .LBB3_1             ; This branch is taken, r4 = 10
>         b       .LBB3_42
> .LBB3_1:                                @ %for.cond3.preheader.lr.ph
>         ldr     r1, [sp, #104]  ; The value in r1 is lost.
>
> Unfortunately I've found it quite hard to isolate that behaviour in
> a reduced test case :/
>

Im trying to decide the best thing to do here...whether we should
investigate this failure (especially since its difficult to reduce) or if
we should revert this for now ... though, it is something that we need to
address I think.


> If you want, I can send more examples of miscompiled code, there
> are a few dozen failures across the test suites I'm running.
>

Should the test case you sent the first time around fail on ARMv7-a as
well?  If so, I should hopefully be able to reproduce it locally which
would help.


> Cheers
> Moritz
>
> > -----Original Message-----
> > From: Renato Golin [mailto:renato.golin at linaro.org]
> > Sent: 20 August 2014 13:44
> > To: Saleem Abdulrasool
> > Cc: LLVM Commits; Moritz Roth; Joey Gouly
> > Subject: Re: [llvm] r215862 - ARM: improve RTABI 4.2 conformance on
> > Linux
> >
> > On 20 August 2014 03:59, Saleem Abdulrasool <compnerd at compnerd.org>
> > wrote:
> > > Could you explain what exactly was broken?  I didn't notice anything
> > in the
> > > generated assembly (but, I could have accidentally overlooked it).
> > Or did
> > > you mean that libgcc's implementation of __aeabi_ldivmod had a bug in
> > it?
> >
> > My memory fails me badly, but here's a long list of bugs about it:
> >
> > http://llvm.org/bugs/show_bug.cgi?id=16387
> > http://llvm.org/bugs/show_bug.cgi?id=17192
> > http://llvm.org/bugs/show_bug.cgi?id=17193
> > http://llvm.org/bugs/show_bug.cgi?id=17881
> >
> > Here's a thread I found that could also help:
> >
> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-
> > 20130729/182718.html
> >
> > Maybe Weiming (or someone else) did fix it and didn't update the bugs.
> >
> > I'll let Moritz chime in on what problems he's finding, as I'm away
> > from the issue for a long time.
> >
> > cheers,
> > --renato
>
>
>
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140820/22d7224b/attachment.html>