[Diffusion] rG825235c140e7: Revert "[Sema] Use the canonical type in function isVector"
Sjoerd Meijer via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Mar 12 04:30:13 PDT 2020
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
More information about the cfe-commits
mailing list