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
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 | ||
---|---|---|
2 | https://reviews.llvm.org/D78929#inline-740137 | |
12 | 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. | |
20 | #19 - #24 can be removed. | |
61 | line #60 - #65 can be removed | |
103 | #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 | ||
---|---|---|
12 | 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. | |
20 | 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 | ||
---|---|---|
26 | 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. | |
92 | 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 | ||
---|---|---|
37 | 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 | ||
---|---|---|
26 | 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 | ||
---|---|---|
37 | 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 | ||
---|---|---|
26 | 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.
https://reviews.llvm.org/D78929#inline-740137
suggested how to format the command.