https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92574
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-11-19
CC| |amker at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We're leaving addressing mode selection to RTL since we keep the
array form on GIMPLE and expand from
ip1_8 = ip_7(D) + 1;
itp1_10 = itp_9(D) + 1;
_1 = bar[ip_7(D)][itp_9(D)];
_2 = bar[ip_7(D)][itp1_10];
_3 = _1 + _2;
_4 = bar[ip1_8][itp_9(D)];
_5 = _3 + _4;
_6 = bar[ip1_8][itp1_10];
_12 = _5 + _6;
return _12;
where then we probably do not aggressively enough fwprop/combine (multi-uses
plus required simplifications likely stand in the way). Straight-line code
"IV"OPTs is missing here and SLSR isn't a 1:1 substitute since it doesn't
even attempt to do addressing-mode selection (but it can help the process).
RTL is faced with "badly" associated mults/adds like
8: {r89:DI=r92:DI+0x1;clobber flags:CC;}
30: {r113:DI=r112:DI<<0x1;clobber flags:CC;}
41: {r122:DI=r113:DI+r89:DI;clobber flags:CC;}
42: r123:DI=[r122:DI*0x8+`bar']
and multi-uses of the individual regs.
