https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91577
--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (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.
