https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
--- 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 checking. So I think relaxing aarch64_mem_pair_lanes_operand is the right way forward, though of course testing will show.
