[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 13.10.14 at 11:40, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> 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?

It is not breaking any ABI - the ABI describes only the calling
convention between global functions. Yet here we're talking
about a static one.

And even for global functions it could, apart from creating an
instance with the "normal" name and following the ABI, create
any number of (local) clones with altered argument/parameter
mappings.

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

No, it is doing exactly what it was asked to do: Pass four inputs (out
of which two have known identical values) to the asm() in _any_
general registers.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.