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

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

Sounds good to me.

Whilst we are here, are any of the other uses of bitcast in arm_mve.td potentially a problem? I took a quick look and because they both converting the inputs and the outputs, I believe they will be OK. (Two wrongs make a right, if you will).



================
Comment at: clang/test/CodeGen/arm-mve-intrinsics/admin.c:1
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple thumbv8.1m.main-none-none-eabi -target-feature +mve.fp -mfloat-abi hard -fallow-half-arguments-and-returns -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg -sroa -early-cse | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-LE
----------------
Is this updated with update_cc_test_checks?

It may make the output more verbose, but it will be more standard.


================
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:
> Surely there is a problem here also?
I don't see why these would be a problem. Can you elaborate?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101606