On 07/08/2017 01:31 AM, Yuri Gribov wrote: > On Sat, Jul 8, 2017 at 12:30 AM, Michael Clark <michaeljcl...@mac.com> 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 [ <retval> ]) > (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