[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs
>>> On 15.02.17 at 15:55, <JBeulich@xxxxxxxx> wrote: >>>> On 15.02.17 at 15:22, <andrew.cooper3@xxxxxxxxxx> wrote: >> bitops.h cannot include asm_defns.h, because the static inlines in > cpumasks.h >> result in forward declarations of the bitops.h contents. Move > ASM_FLAG_OUT() >> to a new asm/compiler.h to compensate. >> >> While making changes, switch bool_t to bool and use named asm parameters. >> >> No (intended) functional change. Without GCC flags, the disassembly is >> identical before and after this patch. With GCC flags however, this patch >> seems to cause GCC to make instruction scheduling decisions. >> >> The first place with significant changes in the disassembly is the the > middle >> of do_domctl(), which switches from: >> >> lock decl 0x1d8(%rax) >> sete %r14b >> mov $0xffffffffffffffea,%rbx >> test %r14b,%r14b >> je ffff82d0801034d4 >> >> to: >> >> lock decl 0x1d8(%rax) >> mov $0x0,%r14d >> mov $0xffffffffffffffea,%rbx >> jne ffff82d0801034d4 >> >> avoiding the use of %r14d as an intermediate for calculating the conditional >> jump, freeing it up for later use. As a result, the compiled code is a > little >> more efficient and smaller overall. > > I have to admit that I find this rather surprising, especially since > (leaving the naming of the asm() operands aside) the preprocessed > source should not change afaict. It being unexpected I think calls > for better understanding what's going on here. This is a result from the bool_t -> bool change and has nothing to do with the use of ASM_FLAG_OUT(). There's also no difference of produced code in a non-debug build. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |