Page MenuHomePhabricator

[NEON] Define vget_high_f16() and vget_low_f16() intrinsics in AArch64 mode only
ClosedPublic

Authored by kosarev on Apr 15 2018, 6:08 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

kosarev created this revision.Apr 15 2018, 6:08 AM

Not really familiar with these 2 intrinsics, I had a quick look at the ACLE:

T vget_high_ST(T 2 a);
T vget_low_ST(T 2 a);

Gets the high, or low, half of a 128-bit vector. There are 24 intrinsics. ARMv8
adds 4 more intrinsics for 128-bit vectors with float64_t and poly64_t lane
type.

I don't read here that they are unavailable in AArch32. Have I missed something?

The NEON Intrinsics Reference (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0073a/index.html) reads like they are AArch64-only.

SjoerdMeijer accepted this revision.Apr 17 2018, 7:25 AM

Yep, agreed, also on the new shiny https://developer.arm.com/technologies/neon/intrinsics it is listed as A64 only.

This revision is now accepted and ready to land.Apr 17 2018, 7:25 AM
This revision was automatically updated to reflect the committed changes.

Sorry, I have second thoughts on this.
This seems more like a doc issue than anything else. There is no reason why this could not be supported in A32. GCC is also supporting this, and removing it is a bit user unfriendly.
Would you mind reverting this?

Sure, will do. Should we treat these intrinsics as ARMv8 or ARMv7/v8? Also, would you mind if I commit a comment under this differential revision explaining the situation?

Thanks, and I am going to try to get some clarity on this doc issue. But looks like it should be "ARMv7, ARMv8", as it used to be. Make sense to comment on this in the commit message, if that's what you mean.

Thanks, and I am going to try to get some clarity on this doc issue. But looks like it should be "ARMv7, ARMv8", as it used to be. Make sense to comment on this in the commit message, if that's what you mean.

These should be available whenever the float16x4_t and float16x8_t types are available. So v7/A32/A64. I have pushed this change to the docs locally; but I don't know when this will make it to public documentation, so you will just have to take my word for it when I say this is a documentation bug and it will be fixed in a future release.

Thanks Sjoerd and James. Just added a comment referring to this revision in rL330420.