[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] arm32: fix build after 063188f4b3
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |