llvm-project/clang/test/CodeGen/arm64_crypto.c
Chandler Carruth 50f9e893f2 [PM] Introduce options to enable the (still experimental) new pass
manager, and a code path to use it.

The option is actually a top-level option but does contain
'experimental' in the name. This is the compromise suggested by Richard
in discussions. We expect this option will be around long enough and
have enough users towards the end that it merits not being relegated to
CC1, but it still needs to be clear that this option will go away at
some point.

The backend code is a fresh codepath dedicated to handling the flow with
the new pass manager. This was also Richard's suggested code structuring
to essentially leave a clean path for development rather than carrying
complexity or idiosyncracies of how we do things just to share code with
the parts of this in common with the legacy pass manager. And it turns
out, not much is really in common even though we use the legacy pass
manager for codegen at this point.

I've switched a couple of tests to run with the new pass manager, and
they appear to work. There are still plenty of bugs that need squashing
(just with basic experiments I've found two already!) but they aren't in
this code, and the whole point is to expose the necessary hooks to start
experimenting with the pass manager in more realistic scenarios.

That said, I want to *strongly caution* anyone itching to play with
this: it is still *very shaky*. Several large components have not yet
been shaken down. For example I have bugs in both the always inliner and
inliner that I have already spotted and will be fixing independently.

Still, this is a fun milestone. =D

One thing not in this patch (but that might be very reasonable to add)
is some level of support for raw textual pass pipelines such as what
Sean had a patch for some time ago. I'm mostly interested in the more
traditional flow of getting the IR out of Clang and then running it
through opt, but I can see other use cases so someone may want to add
it.

And of course, *many* features are not yet supported!
- O1 is currently more like O2
- None of the sanitizers are wired up
- ObjC ARC optimizer isn't wired up
- ...

So plenty of stuff still lef to do!

Differential Revision: https://reviews.llvm.org/D28077

llvm-svn: 290450
2016-12-23 20:44:01 +00:00

95 lines
3.0 KiB
C

// RUN: %clang_cc1 -triple arm64-apple-ios7.0 -target-feature +neon -target-feature +crypto -ffreestanding -Os -S -o - %s | FileCheck %s
// RUN: %clang_cc1 -triple arm64-apple-ios7.0 -target-feature +neon -target-feature +crypto -ffreestanding -fexperimental-new-pass-manager -Os -S -o - %s | FileCheck %s
// REQUIRES: aarch64-registered-target
#include <arm_neon.h>
uint8x16_t test_aese(uint8x16_t data, uint8x16_t key) {
// CHECK-LABEL: test_aese:
// CHECK: aese.16b v0, v1
return vaeseq_u8(data, key);
}
uint8x16_t test_aesd(uint8x16_t data, uint8x16_t key) {
// CHECK-LABEL: test_aesd:
// CHECK: aesd.16b v0, v1
return vaesdq_u8(data, key);
}
uint8x16_t test_aesmc(uint8x16_t data, uint8x16_t key) {
// CHECK-LABEL: test_aesmc:
// CHECK: aesmc.16b v0, v0
return vaesmcq_u8(data);
}
uint8x16_t test_aesimc(uint8x16_t data, uint8x16_t key) {
// CHECK-LABEL: test_aesimc:
// CHECK: aesimc.16b v0, v0
return vaesimcq_u8(data);
}
uint32x4_t test_sha1c(uint32x4_t hash_abcd, uint32_t hash_e, uint32x4_t wk) {
// CHECK-LABEL: test_sha1c:
// CHECK: fmov [[HASH_E:s[0-9]+]], w0
// CHECK: sha1c.4s q0, [[HASH_E]], v1
return vsha1cq_u32(hash_abcd, hash_e, wk);
}
uint32x4_t test_sha1p(uint32x4_t hash_abcd, uint32_t hash_e, uint32x4_t wk) {
// CHECK-LABEL: test_sha1p:
// CHECK: fmov [[HASH_E:s[0-9]+]], w0
// CHECK: sha1p.4s q0, [[HASH_E]], v1
return vsha1pq_u32(hash_abcd, hash_e, wk);
}
uint32x4_t test_sha1m(uint32x4_t hash_abcd, uint32_t hash_e, uint32x4_t wk) {
// CHECK-LABEL: test_sha1m:
// CHECK: fmov [[HASH_E:s[0-9]+]], w0
// CHECK: sha1m.4s q0, [[HASH_E]], v1
return vsha1mq_u32(hash_abcd, hash_e, wk);
}
uint32_t test_sha1h(uint32_t hash_e) {
// CHECK-LABEL: test_sha1h:
// CHECK: fmov [[HASH_E:s[0-9]+]], w0
// CHECK: sha1h [[RES:s[0-9]+]], [[HASH_E]]
// CHECK: fmov w0, [[RES]]
return vsha1h_u32(hash_e);
}
uint32x4_t test_sha1su0(uint32x4_t wk0_3, uint32x4_t wk4_7, uint32x4_t wk8_11) {
// CHECK-LABEL: test_sha1su0:
// CHECK: sha1su0.4s v0, v1, v2
return vsha1su0q_u32(wk0_3, wk4_7, wk8_11);
}
uint32x4_t test_sha1su1(uint32x4_t wk0_3, uint32x4_t wk12_15) {
// CHECK-LABEL: test_sha1su1:
// CHECK: sha1su1.4s v0, v1
return vsha1su1q_u32(wk0_3, wk12_15);
}
uint32x4_t test_sha256h(uint32x4_t hash_abcd, uint32x4_t hash_efgh, uint32x4_t wk) {
// CHECK-LABEL: test_sha256h:
// CHECK: sha256h.4s q0, q1, v2
return vsha256hq_u32(hash_abcd, hash_efgh, wk);
}
uint32x4_t test_sha256h2(uint32x4_t hash_efgh, uint32x4_t hash_abcd, uint32x4_t wk) {
// CHECK-LABEL: test_sha256h2:
// CHECK: sha256h2.4s q0, q1, v2
return vsha256h2q_u32(hash_efgh, hash_abcd, wk);
}
uint32x4_t test_sha256su0(uint32x4_t w0_3, uint32x4_t w4_7) {
// CHECK-LABEL: test_sha256su0:
// CHECK: sha256su0.4s v0, v1
return vsha256su0q_u32(w0_3, w4_7);
}
uint32x4_t test_sha256su1(uint32x4_t w0_3, uint32x4_t w8_11, uint32x4_t w12_15) {
// CHECK-LABEL: test_sha256su1:
// CHECK: sha256su1.4s v0, v1, v2
return vsha256su1q_u32(w0_3, w8_11, w12_15);
}