Re: [AArch64][PATCH 1/2] Fix addressing printing of LDP/STP

[Andre Simoes Dias Vieira <Andre dot SimoesDiasVieira at arm dot com>]

Hi Richard,

Sorry for the delay I have been on holidays.  I had a look and I think you are right.  With these changes Umq and Uml seem to have the same functionality though, so I would suggest using only one.  Maybe use a different name for both, removing both Umq and Uml in favour of Umn, where the n indicates it narrows the addressing mode.  How does that sound to you?

I also had a look at Ump, but that one is used in the parallel pattern for STP/LDP which does not use this "narrowing". So we should leave that one as is.

Cheers,
Andre

________________________________________
From: Richard Sandiford <richard.sandiford@arm.com>
Sent: Thursday, June 14, 2018 12:28:16 PM
To: Andre Simoes Dias Vieira
Cc: gcc-patches@gcc.gnu.org; nd
Subject: Re: [AArch64][PATCH 1/2] Fix addressing printing of LDP/STP

Andre Simoes Dias Vieira <Andre.SimoesDiasVieira@arm.com> writes:
> @@ -5716,10 +5717,17 @@ aarch64_classify_address (struct aarch64_address_info *info,
>    unsigned int vec_flags = aarch64_classify_vector_mode (mode);
>    bool advsimd_struct_p = (vec_flags == (VEC_ADVSIMD | VEC_STRUCT));
>    bool load_store_pair_p = (type == ADDR_QUERY_LDP_STP
> +                         || type == ADDR_QUERY_LDP_STP_N
>                           || mode == TImode
>                           || mode == TFmode
>                           || (BYTES_BIG_ENDIAN && advsimd_struct_p));
>
> +  /* If we are dealing with ADDR_QUERY_LDP_STP_N that means the incoming mode
> +     corresponds to the actual size of the memory being loaded/stored and the
> +     mode of the corresponding addressing mode is half of that.  */
> +  if (type == ADDR_QUERY_LDP_STP_N && known_eq (GET_MODE_SIZE (mode), 16))
> +    mode = DFmode;
> +
>    bool allow_reg_index_p = (!load_store_pair_p
>                           && (known_lt (GET_MODE_SIZE (mode), 16)
>                               || vec_flags == VEC_ADVSIMD

I don't know whether it matters in practice, but that description also
applies to Umq, not just Uml.  It might be worth changing it too so
that things stay consistent.

Thanks,
Richard