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.
Details
- Reviewers
t.p.northover
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. |
Doesn't the first change make this unnecessary? I'm confused.