> Am 08.07.2024 um 16:39 schrieb Eric Botcazou <botca...@adacore.com>:
>
>
>>
>> IIRC at least some array of vector also have vector mode, I'm not sure
>> type_for_mode is an INTEGER_TYPE in that case nor am I sure the max 128
>> bytes size holds here.
>
> Yes, array types may have vector modes.
>
>> There's also array_mode_supported_p which can indicate larger modes are OK.
>
> Yes, but only for ARM and Aarch64 and they return true only if the element
> type already has vector mode.
>
>> That said, when BYTES_BIG_ENDIAN the outcome is better han before.
>
> The wrong code is actually for little-endian targets here, e.g. x86-64.
>
>> If we do not have any BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN
>> target then maybe it's time to retire WORDS_BIG_ENDIAN?
>
> I indeed don't think that we still have this kind of targets.
>
>> Otherwise is there a fallback solution? I wonder if we can fall back to
>> gimplify_variable_sized_compare if gimplify_scalar_mode_aggregate_compare
>> "fails".
>
> Falling back to gimplify_scalar_mode_aggregate_compare should always be OK if
> the mode is not integral scalar, as documented in the description:
>
> /* Gimplify a comparison between two aggregate objects of integral scalar
> mode as a comparison between the bitwise equivalent scalar values. */
>
> static enum gimplify_status
> gimplify_scalar_mode_aggregate_compare (tree *expr_p)
>
> so we could change the guard to match the description exactly:
>
> else if (SCALAR_INT_MODE_P (TYPE_MODE (type)))
Yeah, I prefer this to the != BLKmode check.
So OK with this change.
Richard
> ret = gimplify_scalar_mode_aggregate_compare (expr_p);
> else
> ret = gimplify_variable_sized_compare (expr_p);
>
>
> The new code is only exercised for Ada I think (otherwise there is wrong code
> generated on little-endian targets in other languages as of this writing) and
> it works on all the platforms we test (a bunch) so any additional path would
> be uncovered. If we have evidences that it's not sufficient, then I'm ready
> to amend it, but at the moment it would be a bit of a shot in the dark.
>
> --
> Eric Botcazou
>
>
