This is an archive of the discontinued LLVM Phabricator instance.

[ARM64] Enable feature predicates for NEON / FP / CRYPTO.
Needs ReviewPublic

Authored by kevin.qin on Apr 16 2014, 2:09 AM.

Details

Reviewers
t.p.northover
Summary

AArch64 has feature predicates for NEON and FP instructions. This allows the compiler to generate code without using NEON instructions.
This patch is to implement this. Please review, thanks.

Diff Detail

Event Timeline

Hi Kevin,

I think this mostly looks fine. I've got a couple of minor questions though:

lib/Target/ARM64/ARM64CallingConvention.td
50

Doesn't the first change make this unnecessary? I'm confused.

lib/Target/ARM64/ARM64ISelLowering.cpp
93–94

I *think* these lines are for the SISD support, which probably means they should be under hasNEON. (Actually, I'm rather confused about their entire existence, but that's the only explanation I can come up with).

See comments below.

lib/Target/ARM64/ARM64CallingConvention.td
50

The reason is, f128 is fp used value type, and v2i64 is neon used value type. If user configured backend by '-mattr=+fp-armv8,-neon', then f128 will bitcast to v2i64. Because v2i64 is not legal value type, it will trigger some split functions falling to an assert. Actually, I also confused about calling convention about v2f64, v3f32. They are bit converted to type v2i64 first, and also directly assgin to Qx registers. I don't think v2f64, v4f32 are different from other vectors like v4i32, so the line "CCIfType<[v2f64, v4f32, f128], CCBitConvertToType<v2i64>>," is unnecessary I think.

lib/Target/ARM64/ARM64ISelLowering.cpp
93–94

I think it's not a good implementation for SISD instructions using v16i8 and v8i16. I will move them to hasNEON part in this patch, but I suggest to refactor this in future.

kevin.qin updated this revision to Unknown Object (????).Apr 16 2014, 9:34 PM

Move value type bindings of FPR8 and FPR16 under hasNEON.