Re: x86 branches vs conditional moves
On Sat, Jul 8, 2017 at 12:30 AM, Michael Clark wrote:
> Hi,
>
> Curious about this codegen:
>
> - https://godbolt.org/g/5XxP5S
>
> Why does gcc branch on _Bool, but emits a conditional move for an integer?
> can it emit cmovne instead of branching? also curious where one would change
> this to learn about GCC internals.
Seems to be caused by a limitation in ifconvert pass which can not
handle slightly more complex code in select_bool.
Return there contains implicit != operations on a and b which clobbers
CC register:
(insn 8 7 9 3 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c:SI (symbol_ref:DI ("a"))
(const_int 0 [0]
(insn 9 8 13 3 (set (reg:QI 90 [ ])
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]
(RTL filtered for brevity). This aborts if-conversion in
noce_process_if_block here
if (!bb_valid_for_noce_process_p (then_bb, cond, &then_cost,
&if_info->then_simple))
return false;
because insn_valid_noce_process_p returns false for the first insn above.
> It’s not a bug, but it is a performance issue (*1).
Well, it a performance bug then.
> I was just curious under which conditions the ternary operator is lowered to
> cmov on x86 and found this difference in lowering.
>
> Michael
>
> [1] https://github.com/xiadz/cmov
>
>
> #include
>
> extern int a;
> extern int b;
> extern int c;
> extern _Bool C;
>
> int select_int()
> {
> return c ? a : b;
> }
>
> _Bool select_bool()
> {
> return C ? a : b;
> }
>
> _Bool a_bool()
> {
> return 2;
> }
>
> select_int():
> mov eax, DWORD PTR c[rip]
> testeax, eax
> mov eax, DWORD PTR a[rip]
> cmove eax, DWORD PTR b[rip]
> ret
> select_bool():
> cmp BYTE PTR C[rip], 0
> jne .L8
> mov eax, DWORD PTR b[rip]
> testeax, eax
> setne al
> ret
> .L8:
> mov edx, DWORD PTR a[rip]
> testedx, edx
> setne al
> ret
> a_bool():
> mov eax, 1
> ret
whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?
Hi GCC developers, There was PLUGIN_REGISTER_GGC_CACHES pseudo-events for register_callback in GCC v4.x, but how to migrate it for GCC v6.x? there is no PLUGIN_REGISTER_GGC_CACHES deprecated log in ChangeLog-201X nor git log plugin.h... please give me some hint, thanks a lot! -- Regards, Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/
Re: timeouts/malloc failures in ada tests?
On 7 Jul 2017, at 22:31, Martin Sebor wrote: > > I see large numbers of timeouts in Ada tests on trunk in parallel > run s (make -j96) on x86_64. Messages like the one below appear > in the logs, suggesting some sort of heap corruption. I'm having > trouble reproducing it outside the rest of the test suite (i.e., > by just running the Ada tests by themselves) but maybe I'm doing > it wrong. Unless this is a known problem I can try to pinpoint > it closer if someone could share the magic spell to run just Ada > tests to speed up the debugging. make check-gnat check-ada runs the acats tests and then the gnat tests check-acats runs just the acats tests check-gnat runs just the gnat tests (and your problem is in the gnat tests; the acats tests don't use gnatclean)
Re: x86 branches vs conditional moves
On 07/08/2017 01:31 AM, Yuri Gribov wrote:
> On Sat, Jul 8, 2017 at 12:30 AM, Michael Clark wrote:
>> Hi,
>>
>> Curious about this codegen:
>>
>> - https://godbolt.org/g/5XxP5S
>>
>> Why does gcc branch on _Bool, but emits a conditional move for an integer?
>> can it emit cmovne instead of branching? also curious where one would change
>> this to learn about GCC internals.
>
> Seems to be caused by a limitation in ifconvert pass which can not
> handle slightly more complex code in select_bool.
>
> Return there contains implicit != operations on a and b which clobbers
> CC register:
> (insn 8 7 9 3 (set (reg:CCZ 17 flags)
> (compare:CCZ (mem/c:SI (symbol_ref:DI ("a"))
> (const_int 0 [0]
> (insn 9 8 13 3 (set (reg:QI 90 [ ])
> (ne:QI (reg:CCZ 17 flags)
> (const_int 0 [0]
> (RTL filtered for brevity). This aborts if-conversion in
> noce_process_if_block here
> if (!bb_valid_for_noce_process_p (then_bb, cond, &then_cost,
> &if_info->then_simple))
> return false;
> because insn_valid_noce_process_p returns false for the first insn above.
>
>> It’s not a bug, but it is a performance issue (*1).
>
> Well, it a performance bug then.
Other things to consider.
It's generally a good thing from an optimization pipeline standpoint to
turn jumpy code into conditional moves and to do so as early as
possible. So I'd really look at the gimple optimizers first before the
low level RTL if conversion.
Second, final selection of a conditional move should be dependent upon
the predictability of the conditional branches it will eliminate. cmove
shines when the branches are unpredictable, but if the branches are
predictable, then you're better off leaving them as branches.
Jeff
