[Diffusion] rG825235c140e7: Revert "[Sema] Use the canonical type in function isVector"

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

> I'm still not sure why __fp16, which is a storage-only type, is used for the element type of float16x4_t if we want to avoid promotion to a float vector type.

About the types: `__fp16` this is the older, storage-only type. So, just historically, I think this element type was used to describe the neon vectors, which translates to vectors with elements of i16 or f16, which all seems fine.

> Was there a discussion on llvm-dev or phabricator?

I don't think this is necessary, because this is how it's been from let's say the beginning.

> Can we change the element type of the vector to _Float16?

I don't see a benefit of doing this, and making this perhaps intrusive change.

> It seems that the original plan discussed on llvm-dev (http://lists.llvm.org/pipermail/cfe-dev/2017-May/053768.html) was to introduce _Float16 and use it instead of __fp16 for ARMv8.2-A, but the subsequent patches that were committed are making NeonEmitter.cpp emit typedefs of vectors that have __fp16 as the element type.

Then `_Float16` came along, which is a proper half type (not a storage only type), is defined in a C11 extension, and should be used for the ARMv8.2-A native half instructions; the semantics of `__fp16` and `_Float16` are different, and as a result using `__fp16` for the v8.2 half FP instructions is not an option, so it is not a matter of using `_Float16` instead of `__fp16`.

As I said, your problem wasn't clear to me, so let's look at your example:

> For example, in vneg_f16, __p0 is promoted to a vector of float before it's negated.
> 
> __ai float16x4_t vneg_f16(float16x4_t __p0) {
> 
>   float16x4_t __ret;
>    __ret = -__p0;
>    return __ret;
> 
> }

when I compile this and emit llvm ir I get this:

  define dso_local <2 x i32> @vneg_f16(<2 x i32> %__p0.coerce) local_unnamed_addr #0 {
  entry:
    %0 = bitcast <2 x i32> %__p0.coerce to <4 x half>
    %fneg = fneg fast <4 x half> %0
    %1 = bitcast <4 x half> %fneg to <2 x i32>
    ret <2 x i32> %1
  }

so far so good I think: this shows a fneg on vector of halfs.

Where and when do you see problems? Can you describe this, and also provide your compile commands?


BRANCHES
  master, release/10.x

Users:
  ahatanak (Author)

https://reviews.llvm.org/rG825235c140e7