Re: [Xen-devel] [PATCH] arm32: fix build after 063188f4b3

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 13 Oct 2014, Jan Beulich wrote:
> >>> On 10.10.14 at 19:03, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Fri, 10 Oct 2014, Jan Beulich wrote:
> >> >>> On 10.10.14 at 16:32, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >> > I would appreciate if Jan could post the assembly he is getting.
> >> 
> >> Here you go:
> >> 
> >>    .type   exynos_smc.constprop.1, %function
> >> exynos_smc.constprop.1:
> >> .LFB277:
> >>    .loc 1 40 0
> >>    .cfi_startproc
> >>    @ args = 0, pretend = 0, frame = 0
> >>    @ frame_needed = 0, uses_anonymous_args = 0
> >>    @ link register save eliminated.
> >> .LVL52:
> >>    .loc 1 43 0
> >>    mvn     r2, #3
> >>    mov     r3, #0
> > 
> > That cannot be right: ~3 ends up in r2, while r2 should be 0.
> > This doesn't look like an optimization: it looks like a bug.
> > Am I missing something?
> 
> Yes - the asm() doesn't enforce the specific registers (and it can't
> due to the lack of suitable constraints), and hence the compiler
> is permitted to use other than the registers checked for in the
> subsequent .if-s. It is the purpose of this patch to address this.

Is ipa-cp allowed to break the ABI?
I thought it was not, maybe it is.

Because in this case gcc is not upholding the definition of noinline: it
is not respecting the calling convention. r2 should be set to 0 and r1
should be set to "cpu" before branching to exynos_smc.constprop.1.
Inside exynos_smc.constprop.1 gcc can do whatever it wants (even though
I fail to see why gcc wants to assign ~3 to r2 before smc).

I could understand if gcc was assigning the constant function arguments
right after the call, instead of before the call, but it is not what it
is doing here, or it is doing it incorrectly.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel