https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101925
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |ebotcazou at gcc dot gnu.org
Status|NEW |ASSIGNED
Target Milestone|--- |10.4
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I suppose when the vectorizer detects grouped loads/stores in
vect_analyze_data_ref_accesses we have to give up.
OTOH even w/o grouped loads the vectorizer will rewrite a.b.c[i] to
MEM_REFs based on 'a' and thus not properly retain the reverse storage
attributes.
Which means a fix in vect_analyze_data_refs would be better? OTOH other
loop optimizations also rely on refs that pass through data-ref analysis
to be reconstructible from the analyzed base + offset so even better
fail in data-ref analysis already? I suppose that for regular loop opts
it might work to just set REF_REVERSE_STORAGE_ORDER on a MEM_REF
created from base + offset when the original DR_REF had that set?
But when vectorizing we're using a vector type for the access and clearly
the storage order bits apply to the component (which we _usually_ do not
change).
Eric, any suggestions? Given the above I'd just fix vect_analyze_data_refs
and leave other loop opts "latent" (I can't actually think of a broken one)?
