[PATCH] D101606: [ARM][MVE] vcreateq lane ordering for big endian

[Tomas Matheson via Phabricator via cfe-commits]

tmatheson added inline comments.


================
Comment at: clang/test/CodeGen/arm-mve-intrinsics/admin.c:66
 // CHECK-NEXT:    [[TMP1:%.*]] = insertelement <2 x i64> [[TMP0]], i64 [[B:%.*]], i64 1
 // CHECK-NEXT:    ret <2 x i64> [[TMP1]]
 //
----------------
MarkMurrayARM wrote:
> dmgreen wrote:
> > MarkMurrayARM wrote:
> > > Surely there is a problem here also?
> > I don't see why these would be a problem. Can you elaborate?
> I'm wondering if they need to be swapped in the BE case.
vcreateq is not endianness aware, it just inserts the two given 64 bit values `a` and `b` into the low and high lanes respectively. The bit representation of each 64 bit int will be different but that is not shown here. Therefore the IR is the same for big and little endian.

I have also confirmed locally with runtime output:
```
    uint64x2_t w = vcreateq_u64(0x0000000000000001, 0x0000000000000002);
    printf("%d:%llu\n", 0, vgetq_lane_u64(w, 0));
    printf("%d:%llu\n", 1, vgetq_lane_u64(w, 1));
```
which gives for both little and bit endian (with this patch):
```
0:1
1:2
```


================
Comment at: clang/test/CodeGen/arm-mve-intrinsics/admin.c:116
 // CHECK-NEXT:    [[TMP1:%.*]] = insertelement <2 x i64> [[TMP0]], i64 [[B:%.*]], i64 1
 // CHECK-NEXT:    ret <2 x i64> [[TMP1]]
 //
----------------
MarkMurrayARM wrote:
> And a problem here also (with BE)?
See above


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101606/new/

https://reviews.llvm.org/D101606