[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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)?