https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87055
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Target| |x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-08-22
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Isn't that a target (cost) issue?
Failed to match this instruction:
(set (reg:SI 94)
(mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI (plus:SI (reg/v:SI 89
[ i ])
(const_int 1 [0x1])) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(symbol_ref:DI ("a") [flags 0x2] <var_decl 0x7fb5206f3e10 a>)) [1
a S4 A32]))
looks like the usual type issue to me since it works with i being long where
combine then successfully matches
(set (reg:SI 93)
(mem:SI (plus:DI (mult:DI (reg/v:DI 89 [ i ])
(const_int 4 [0x4]))
(const:DI (plus:DI (symbol_ref:DI ("a") [flags 0x2] <var_decl
0x7fcf728d6e10 a>)
(const_int 4 [0x4])))) [1 a S4 A32]))
I guess we need to exploit the undefined overflow of i+1 on GIMPLE though
which would mean handling this in a IVOPTs-like pass (SLSR?). Or we need
to promote address computation parts (array indexes) earlier. Or we need
to avoid using a DImode multiply for SImode indexes... (we only need
a widening multiply).
Anyway, clang correctly doesn't optimize
int a[256];
int foo (unsigned int i)
{
return a[i+1];
}
I think we have a duplicate of this bug somewhere.
