https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
My patch for PR58416 doesn't fix this because here the issue is we are creating
a load/store "no-op" move based on accesses that are never executed at runtime
since we're doing the re-materialization at places not related to the
scalar accesses.
I'll note this also causes UB by accessing a.b after a store to a.a (GCC
allows this as an extension).
If SRA would know we need to re-materialize an object at the time we do
analyze_access_subtree we could fix-up similar to PR58416, but I think
we don't know this.
So instead SRA should chose more optimal placement for the re-materializing
loads and stores using LCM. Note to be fully correct (never access when
it wasn't accessed in the untransformed code) it might need to emit multiple
copies for this.
We end up with
Access trees for a (UID: 2999):
access { base = (2999)'a', offset = 0, size = 32, expr = a.b, type = float,
reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 1, grp_scalar_write = 1,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}
while there's grp_assignment_read/write there's not the opposite
(grp_call_read/write), a flag to note we need re-materialization
after a store or before a read.
Note without a target hook telling whether we have a "true" FP load/store
instruction not SRAing in this case might pessimize quite some code(?)
