================
@@ -0,0 +1,58 @@
+// RUN: cir-opt %s -cir-flatten-cfg -o - | FileCheck %s
+
+module {
+ cir.func @foo() {
+ cir.scope {
+ %0 = cir.alloca !cir.int<u, 32>, !cir.ptr<!cir.int<u, 32>>, ["a", init]
{alignment = 4 : i64}
+ %1 = cir.const #cir.int<4> : !cir.int<u, 32>
+ cir.store %1, %0 : !cir.int<u, 32>, !cir.ptr<!cir.int<u, 32>>
+ }
+ cir.return
+ }
+// CHECK: cir.func @foo() {
+// CHECK: cir.br ^bb1
----------------
erichkeane wrote:
> These checks are the same checks that are present in this test in the
> incubator (except for the fact that we're not abbreviating the int types
> upstream yet). The test is verifying the flattening pass in isolation, and
> since the flattening pass doesn't remove unneeded blocks, the output will
> stay as it is here.
My question was really "should it?" to the "the flattening pass doesn't remove
unneeded blocks". But TBH my understanding of what we should expect out of
individual passes, or how passes are designed is lacking.
https://github.com/llvm/llvm-project/pull/130861
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
