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

Moritz Roth moritz.roth at arm.com
Wed Aug 20 09:59:05 PDT 2014


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.

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?]
	@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 :/

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

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








More information about the llvm-commits mailing list