[PATCH] D70133: [ARM, MVE] Add intrinsics for 'administrative' vector operations.

Simon Tatham via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 13 04:16:02 PST 2019


simon_tatham marked 3 inline comments as done.
simon_tatham added inline comments.


================
Comment at: clang/include/clang/Basic/arm_mve.td:384
+  let params = !foldl([]<Type>, T.All, tlist, srctype, !listconcat(tlist,
+  !if(!eq(!cast<string>(desttype),!cast<string>(srctype)),[],[srctype]))) in {
+    def "vreinterpretq_" # desttype: Intrinsic<
----------------
dmgreen wrote:
> Indent this line by an extra 4 spaces.
> 
> I'm going to have to trust you that it's doing the right thing. The !eq has to be on two strings?
Yes, unfortunately – it would be nice to be able to `!eq` two defs, but it only accepts strings.


================
Comment at: clang/test/CodeGen/arm-mve-intrinsics/admin.c:1568
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:    [[TMP0:%.*]] = zext i16 [[A:%.*]] to i32
+// CHECK-NEXT:    [[TMP1:%.*]] = insertelement <8 x i16> [[B:%.*]], i16 [[A]], i32 6
----------------
dmgreen wrote:
> What's this zext about? Is it just left over from code that was removed?
`MveEmitter` automatically promotes smaller integer types to `i32`, on the assumption that you were probably going to pass them to IR intrinsics which will instruction-select into things taking a GPR as input.

For my next batch of intrinsics I'm working on a system for suppressing that promotion in cases where it isn't what you wanted after all. Now you mention it, that might be a thing to pull out and apply here as well.


================
Comment at: clang/test/CodeGen/arm-mve-intrinsics/admin.c:1671
+//
+float16x8_t test_vuninitializedq_polymorphic_f16(float16x8_t (*funcptr)(void))
+{
----------------
dmgreen wrote:
> I see. This is the "non-evaluating" part. It looks odd from a C perspective.
Slightly, although it's no more odd than `sizeof` or `__typeof` for only using the type of its argument and not actually evaluating it. But it's what ACLE specifies!

(I think, rather like I just mentioned in D70088, that the use case is for polymorphism within something like a C++ template – if you have the vector type as a template parameter, this allows you to generate an uninit value of the same vector type reasonably easily, without having to write your own system of C++ template specializations that select the right explicitly suffixed intrinsic.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70133





More information about the cfe-commits mailing list