https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125730
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs-bisection
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
So IVOPTs replaces
# PT = nonlocal null
first_kw_arg_12 = argnames_11(D) + _2;
...
- # PT = nonlocal null
- _5 = values_16(D) + _4;
# PT = nonlocal escaped null { D.4624 } (escaped)
fetched_value.1_6 = fetched_value;
- *_5 = fetched_value.1_6;
with
+ _20 = (sizetype) values_16(D);
+ _26 = (sizetype) argnames_11(D);
+ _27 = _20 - _26;
+ # PT = nonlocal null
+ _28 = first_kw_arg_12 + _27;
+ MEM[(char * * *)_28 + ivtmp.11_8 * 1] = fetched_value.1_6;
that's bogus IVOPT. If it really wanted to do such fancy opt it would
need to compute first_kw_arg_12 + _27 with integer arithmetic. It has
IV struct:
SSA_NAME: _5
Type: char * * *
Base: (char * * *) (((unsigned long) first_kw_arg_12 + (unsigned long)
values_16(D)) - (unsigned long) argnames_11(D))
Step: 8
Object: 0
Biv: N
Overflowness wrto loop niter: No-overflow
it seems the issue is that while the affine combination for the address
has integer type, move_pointer_to_base selects the first pointer component
it sees.
Also we have 1 * _12 + 1 * _16 + -1 * _11 where _12 = _11 + _2, so there's
missed simplification resulting from missed expansion (of a pointer plus)
which is what leads us down this rabbit hole.
