https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What we see is an effect of 3 different optimizations, one is loop unrolling
(cunroll in this case), another one is ivopts that moves the h array references
out of the loops but still has separate:
ivtmp.40_47 = (unsigned long) &h;
_17 = (unsigned long) &h;
_30 = _17 + 96;
...
h ={v} {CLOBBER};
ivtmp.30_33 = (unsigned long) &h;
_41 = (unsigned long) &h;
_36 = _41 + 96;
and finally dom3's VN which replaces ivtmp.30_33 initializer with ivtmp.40_47
and _36 with _30.
If what the cfg expand var partition code is as designed (I think other passes
do it too, e.g. compute_live_vars/live_vars_at_stmt relies on it too), then we
need to somehow avoid VN of &var across var ={v} {CLOBBER} stmt, but it isn't
really clear to me how.
Unless we change loop unrolling so that the different loop iterations if there
is a var clobber in the loop actually have different variables (the first
iteration the original var and other iterations that var's copies; perhaps only
for addressable vars?). Then naturally VN couldn't merge those and the RTL
partitioning code could decide to put them into the same or different partition
and later RTL opts could CSE the addresses.
