https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|amker at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Last reconfirmed|2019-04-28 00:00:00 |2026-2-2
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm sure Bin is not working on this. We now have FRE (any forwarding pass will
do this):
- _15 = &final_counts + 18446744073709551612;
- _1 = MEM[(unsigned int *)_15 + ivtmp.9_3 * 4];
+ _1 = MEM[(unsigned int *)&final_counts + -4B + ivtmp.9_3 * 4];
Note we do not print literal zero for the constant offset in a TARGET_MEM_REF,
but it always exists because it carries TBAA info. As said
&final_counts + 18446744073709551612 is considered an invaraint in GIMPLE
and thus is propagated to all uses. We are able to legitimize this via
maybe_canonicalize_mem_ref_addr which distributes a &MEM[&final_counts +
18446744073709551612] which is how these invariants are carried.
The only way to prevent propagating those would be to make them
appear as non-invariant. Possibly a &TMR[&final_counts + 18446744073709551612]
might do, but that's of course prone to fold back to a &MEM_REF.
The other way would be to recover from this at RTL expansion time where
we should notice the addresss isn't legitimate.
Possibly IVOPTs could anticipate &final_counts + 18446744073709551612
isn't a good base to chose, but then if final_counts is on stack there's
a stack offset to be considered. Or with -fPIE/PIC for globals, which
the GIMPLE-level analysis also does not take into account well.
