This patch validates that llc has implemented the AIX ABI for _Complex float, _Complex double in 32 and 64 bit modes. I've also validated the correct handling of ppc_fp128 _Complex, though we don't have a front-end that is expected to emit such IR yet.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM but I will leave it up for a bit so other reviewers have a chance to look at it.
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
1 ↗ | (On Diff #278886) | https://reviews.llvm.org/D78929#inline-740137 |
11 ↗ | (On Diff #278886) | It seems all align xx in this test are unnecessary, so you can simplify the testcase by removing them. Also attributes like noinline nounwind optnone can be removed. |
19 ↗ | (On Diff #278886) | #19 - #24 can be removed. |
60 ↗ | (On Diff #278886) | line #60 - #65 can be removed |
102 ↗ | (On Diff #278886) | #102 - #107 can be removed |
I'll format the RUN steps as suggested but with respect to the other suggestions, I prefer to keep the test as-is.
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
11 ↗ | (On Diff #278886) | I generated the IR from C code, hence the align 8. I don't think it's strictly necessary but I'd like to keep the IR consistent with what we'd expect from a producer. I don't feel the alignment obfuscates the test. Re attributes: I wanted optnone because optimization can elide the calling registers loads if it already knows the registers already hold the desired value. I wanted the expected register state right next to the bl/blr so I chose no-opt for this purpose. |
19 ↗ | (On Diff #278886) | If we're ok with returning an uninitialized value yes, and it probably would work as expected, however, backends reserve the right to discard use of uninitialized values. Theoretically, a backend could discard the return register initialization all together. Mitigated by optnone, however, I think it's best not to return an uninitialized value. |
Modified the tests to work at opt. Replaced initialization of return values with literals to simplify the IR.
added some commentary notes for the review.
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
25 ↗ | (On Diff #279654) | Note this is lfs and not lfd. llc appears to be smart enough to use a 4 byte lfs to populate the register when possible. |
91 ↗ | (On Diff #279654) | The bit patterns were chosen deliberately to avoid redundancy otherwise llc will initialize the call registers with reg copies rather than lfd. |
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
36 ↗ | (On Diff #279654) | Just a question, why we would like to branch to anchor here? Does it help us with testing _Complex? |
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
25 ↗ | (On Diff #279654) | I guess it's because llc is not default to -O0, if you add -O0, you will get lfd back. And that leads me to think that you may want to add optimization level -O0 since you aimed at testing optnone scenario. Also you can test other optimization level if you are confident that the compiler is doing the right thing. |
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
36 ↗ | (On Diff #279654) | Yes, it's so that there are no stray instructions that weave into the stfd's that are expected to follow the call to dblCmplxRetCallee. ; CHECK-NEXT: stfd 1, 0([[REG]]) is not ideal because we don't care what order the stfd's come out and ; CHECK-DAG: stfd 1, 0([[REG]]) without the anchor would not require the stfd's to come immediately after the callee. |
llvm/test/CodeGen/PowerPC/aix-complex.ll | ||
---|---|---|
25 ↗ | (On Diff #279654) | The original intent of optnone was to make it easier to CHECK-NEXT against the expected register read/writes around the bl/blr. Instead I adapted the test in a way to run at opt. The intention of the test isn't to validate lfs/lfd between opt/noopt. I don't think the -O0 run is needed. If this test is run at -O0 it will fail, however, I think that's true of many LLVM tests. |
Hi @cebowleratibm, it seems test is located in wrong place: test/CodeGen/PowerPC instead of llvm/test/CodeGen/PowerPC.