https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91577
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #2) > (In reply to Richard Biener from comment #1) > > So it looks like load/store-lanes has actual (aggregate) memory references > > as > > arguments: > > > > # .MEM_209 = VDEF <.MEM_84> > > vect_array.27 = .LOAD_LANES (MEM <real(kind=8)[4]> [(real(kind=8) *)&z]); > > > > but then it doesn't expect those to be expanded to a register - but here > > we get > > > > (gdb) p debug_rtx (mem) > > (reg/v:OI 110 [ z ]) > > > > there's nothing in the GIMPLE IL forcing the argument to be addressable > > and I guess it's too late to do anything about this in > > expand_load_lanes_optab_fn. > > I guess we could use assign_stack_temp, but obviously it'd be > better not to. > > (If the input is already a register, the two-argument version > would be better as two permutes.) > > > There's discover_nonconstant_array_refs (a hack, IMHO) which could be > > (ab-)used to handle this case (mark .LOAD_LANES args and .STORE_LANES > > destination as TREE_ADDRESSABLE). > > Sounds like a nice work-around for now. Can you take care of that? I'm not set up for aarch64/arm testing.
