--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to avieira from comment #5)
> I have been looking at this and the problem does indeed lie with the
> register not being a hard reg because aarch64_mem_pair_lanes_operand invokes
> aarch64_legitimate_address_p with 1 for the strict_p argument.
> Changing that to a 0 yields the desired results for this testcase. Also good
> to note that this is not an ilp32 issue only, because of this we would also
> miss cases where the argument hard-register would not be successfully
> combined into the load/store. Say if for instance the argument in the test
> function were a pointer to the pointer we are addressing.
> I will proceed to run tests now, if someone knows why that "strict_p" was
> being set to 1 please let me know, I am unfamiliar with this code and fear
> this might be too big a hammer.
I think requiring strict address checking in aarch64_mem_pair_lanes_operand is
overly conservative indeed. The store_pair_lanes<mode> pattern that uses it is
supposed to be created at combine-time at which point we want to allow any type
of register. Then during reg-alloc the Uml constraint enforces the strict
So I think relaxing aarch64_mem_pair_lanes_operand is the right way forward,
though of course testing will show.