On 16/07/15 08:56, Christophe Lyon wrote:
AdvSIMD vget_lane tests currently fail on armeb targets when dealing
with vectors of 2 64-bits elements. This patches fixes it, by adding a
code fragment similar to what is dones in other cases. I could have
simplified it a bit given that the vector width is known, but I chose
to hardcode 'reg_nelts = 2' to keep the code closer to what is done
elsewhere.
OK for trunk?
Christophe
2015-07-16 Christophe Lyon <christophe.l...@linaro.org>
* config/arm/neon.md (neon_vget_lanev2di): Handle big-endian
targets.
I see we do this for other lanewise patterns as well.
Has this been tested on an arm big-endian target?
If so, ok for trunk.
Thanks,
Kyrill
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 654d9d5..59ddc5b 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -2736,6 +2736,19 @@
(match_operand:SI 2 "immediate_operand" "")]
"TARGET_NEON"
{
+ if (BYTES_BIG_ENDIAN)
+ {
+ /* The intrinsics are defined in terms of a model where the
+ element ordering in memory is vldm order, whereas the generic
+ RTL is defined in terms of a model where the element ordering
+ in memory is array order. Convert the lane number to conform
+ to this model. */
+ unsigned int elt = INTVAL (operands[2]);
+ unsigned int reg_nelts = 2;
+ elt ^= reg_nelts - 1;
+ operands[2] = GEN_INT (elt);
+ }
+
switch (INTVAL (operands[2]))
{
case 0: