[Bug target/91577] [10 Regression] ICE in expand_load_lanes_optab_fn, at internal-fn.c:163 since r274922

[rsandifo at gcc dot gnu.org]

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.