Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> writes: > Hi Andre, > On 07/06/18 18:02, Andre Simoes Dias Vieira wrote: >> Hi, >> >> See below a patch to address PR 83009. >> >> Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran. >> Ran the adjusted testcase for -mabi=ilp32. >> >> Is this OK for trunk? >> >> Cheers, >> Andre >> >> PR target/83009: Relax strict address checking for store pair lanes >> >> The operand constraint for the memory address of store/load pair lanes was >> enforcing strictly hardware registers be allowed as memory addresses. We >> want >> to relax that such that these patterns can be used by combine, prior >> to reload. >> During register allocation the register constraint will enforce the correct >> register is chosen. >> >> gcc >> 2018-06-07 Andre Vieira <andre.simoesdiasvie...@arm.com> >> >> PR target/83009 >> * config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand): Make >> address check not strict prior to reload. >> >> gcc/testsuite >> 2018-06-07 Andre Vieira <andre.simoesdiasvie...@arm.com> >> >> PR target/83009 >> * gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests. > > diff --git a/gcc/config/aarch64/predicates.md > b/gcc/config/aarch64/predicates.md > index > f0917af8b4cec945ba4e38e4dc670200f8812983..30aa88838671bf343a883077c2b606a035c030dd > 100644 > --- a/gcc/config/aarch64/predicates.md > +++ b/gcc/config/aarch64/predicates.md > @@ -227,7 +227,7 @@ > (define_predicate "aarch64_mem_pair_lanes_operand" > (and (match_code "mem") > (match_test "aarch64_legitimate_address_p (GET_MODE (op), XEXP (op, > 0), > - true, > + reload_completed, > ADDR_QUERY_LDP_STP_N)"))) > > > If you want to enforce strict checking during reload and later then I think > you need to use reload_in_progress || reload_completed ?
That was the old way, but it would be lra_in_progress now. However... > I guess that would be equivalent to !can_create_pseudo (). We should never see pseudos when reload_completed, so the choice shouldn't really matter then. And I don't think we should use lra_in_progress either, since that would make the checks stricter before RA has actually happened, which would likely lead to an unrecognisable insn ICE if recog is called during one of the LRA subpasses. So unless we know a reason otherwise, I think this should just be "false" (like it already is for aarch64_mem_pair_operand). Thanks, Richard
