This enables the post RA scheduler and AES fusion for the Neoverse cores.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AArch64/AArch64.td | ||
---|---|---|
1016 | If this is adding crypto... shouldn't there be a test for that? The one in TargetParserTest? |
My understanding of FeaturePostRAScheduler was that is was better/more important for in-order cores than out of order. Can you enable it for the A55 too (and UseAA)?
While I probably agree with that, it doesn't do any harm, and can do some good. Another way to look at it is a consistency fix because other big(ger) cores have this too.
I am surprised about the A55, I thought I had fixed that!
llvm/lib/Target/AArch64/AArch64.td | ||
---|---|---|
1016 | From llvm/unittests/Support/TargetParserTest.cpp: ARMCPUTestParams("neoverse-n2", "armv8.5-a", "crypto-neon-fp-armv8", AArch64::AEK_CRC | AArch64::AEK_CRYPTO | AArch64::AEK_FP | AArch64::AEK_SIMD | AArch64::AEK_FP16 | AArch64::AEK_RAS | AArch64::AEK_LSE | AArch64::AEK_SVE | AArch64::AEK_DOTPROD | AArch64::AEK_RCPC | AArch64::AEK_RDM | AArch64::AEK_MTE | AArch64::AEK_SSBS | AArch64::AEK_SB | AArch64::AEK_SVE2 | AArch64::AEK_SVE2BITPERM | AArch64::AEK_BF16 | AArch64::AEK_I8MM, "8.5-A"), And from llvm/include/llvm/Support/AArch64TargetParser.def: AARCH64_CPU_NAME("neoverse-n2", ARMV8_5A, FK_CRYPTO_NEON_FP_ARMV8, false, So, that all seems alright from the front-end and driver point of view, although looks like I need to add a driver test. |
OK sure. Lets do these things.
LGTM.
llvm/test/CodeGen/AArch64/misched-fusion-aes.ll | ||
---|---|---|
15 | + neoverse-v1 |
If this is adding crypto... shouldn't there be a test for that? The one in TargetParserTest?