]> git.ipfire.org Git - thirdparty/gcc.git/commit
vect: Fix VEC_WIDEN_PLUS_HI/LO choice for big-endian [PR118891]
authorRichard Sandiford <richard.sandiford@arm.com>
Sat, 26 Jul 2025 17:38:46 +0000 (18:38 +0100)
committerRichard Sandiford <richard.sandiford@arm.com>
Sat, 26 Jul 2025 17:38:46 +0000 (18:38 +0100)
commitd755d8107d336ca1a5805370fb6c5fb4df2c5da4
treea97cfe5b658e8f55d20673749afd4f334641f21f
parent3120ebf3228fde693beaafd5dcbb2aa9dfb48f46
vect: Fix VEC_WIDEN_PLUS_HI/LO choice for big-endian [PR118891]

In the tree codes and optabs, the "hi" in a vector hi/lo pair means
"most significant" and the "lo" means "least significant", with
sigificance following GCC's normal endian expectations.  Thus on
big-endian targets, the hi part handles the first half of the elements
in memory order and the lo part handles the second half.

For tree codes, supportable_widening_operation first chooses hi/lo
pairs based on little-endian order and then uses:

  if (BYTES_BIG_ENDIAN && c1 != VEC_WIDEN_MULT_EVEN_EXPR)
    std::swap (c1, c2);

to adjust.  However, the handling for internal functions was missing
an equivalent fixup.  This led to several execution failures in vect.exp
on aarch64_be-elf.

If the hi/lo code fails, the internal function handling goes on to try
even/odd.  But I couldn't see anything obvious that would put the even/
odd results back into the right order later, so there might be a latent
bug there too.

gcc/
PR tree-optimization/118891
* tree-vect-stmts.cc (supportable_widening_operation): Swap the
hi and lo internal functions on big-endian targets.

(cherry picked from commit ec54a14239b12d03c600c14f3ce9710e65cd33f1)
gcc/tree-vect-stmts.cc