This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: LRA: handle memory constraints that accept more than "m"
- From: Jeff Law <law at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org, szabolcs dot nagy at arm dot com, richard dot sandiford at arm dot com
- Date: Sun, 17 Nov 2019 14:02:31 -0700
- Subject: Re: LRA: handle memory constraints that accept more than "m"
- References: <mptv9ruloyx.fsf@arm.com>
On 11/8/19 2:03 AM, Richard Sandiford wrote:
> LRA allows address constraints that are more relaxed than "p":
>
> /* Target hooks sometimes don't treat extra-constraint addresses as
> legitimate address_operands, so handle them specially. */
> if (insn_extra_address_constraint (cn)
> && satisfies_address_constraint_p (&ad, cn))
> return change_p;
>
> For SVE it's useful to allow the same thing for memory constraints.
> The particular use case is LD1RQ, which is an SVE instruction that
> addresses Advanced SIMD vector modes and that accepts some addresses
> that normal Advanced SIMD moves don't.
>
> Normally we require every memory to satisfy at least "m", which is
> defined to be a memory "with any kind of address that the machine
> supports in general". However, LD1RQ is very much special-purpose:
> it doesn't really have any relation to normal operations on these
> modes. Adding its addressing modes to "m" would lead to bad Advanced
> SIMD optimisation decisions in passes like ivopts. LD1RQ therefore
> has a memory constraint that accepts things "m" doesn't.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> Richard
>
>
> 2019-11-08 Richard Sandiford <richard.sandiford@arm.com>
>
> gcc/
> * lra-constraints.c (valid_address_p): Take the operand and a
> constraint as argument. If the operand is a MEM and the constraint
> is a memory constraint, check whether the eliminated form of the
> MEM already satisfies the constraint.
> (process_address_1): Update calls accordingly.
>
> gcc/testsuite/
> * gcc.target/aarch64/sve/acle/asm/ld1rq_f16.c: Remove XFAIL.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_f32.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_f64.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_s16.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_s32.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_s64.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_u16.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_u32.c: Likewise.
> * gcc.target/aarch64/sve/acle/asm/ld1rq_u64.c: Likewise.
OK. Obviously I'll be on the lookout for any fallout on other targets.
jeff