> 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)))
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
