https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85017
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-03-21
Component|rtl-optimization |tree-optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's at least smaller. Probably a cost issue, RTL fwprop is usually handling
this kind of stuff (and of course combine). fwprop2 sees
(insn 7 3 8 2 (parallel [
(set (reg:SI 92 [ i ])
(plus:SI (reg/v:SI 89 [ c ])
(const_int 20 [0x14])))
(clobber (reg:CC 17 flags))
]) "t.c":5 221 {*addsi_1}
(expr_list:REG_DEAD (reg/v:SI 89 [ c ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))))
(insn 8 7 9 2 (set (reg:DI 93 [ i ])
(sign_extend:DI (reg:SI 92 [ i ]))) "t.c":6 149 {*extendsidi2_rex64}
(expr_list:REG_DEAD (reg:SI 92 [ i ])
(nil)))
(insn 9 8 14 2 (set (reg:QI 94)
(mem/j:QI (plus:DI (reg:DI 93 [ i ])
(symbol_ref:DI ("arr") [flags 0x2] <var_decl 0x7f6661743e10
arr>)) [0 arr S1 A8])) "t.c":6 88 {*movqi_internal}
(expr_list:REG_DEAD (reg:DI 93 [ i ])
(nil)))
where it is probably confused by the sign-extend. Note on RTL overflow
is well-defined and I'm quite sure movb arr+20(%rax), %al behaves
differently from addl $20, %eax in that if %eax is 0xffffffff it will
access at 0x100000013 rather than 0x00000013.
This means it is a missed optimization on GIMPLE where we could widen
the add because signed overflow is undefined or perform addressing
mode selection on GIMPLE.
