This patch implements the builtins for cmplxl by utilising
__builtin_complex. This builtin is implemented to match XL
functionality.
Details
- Reviewers
nemanjai NeHuang - Group Reviewers
Restricted Project - Commits
- rG9d4faa8ac3e7: [PowerPC] Implement cmplxl builtins
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
clang/include/clang/Basic/BuiltinsPPC.def | ||
---|---|---|
146 | Please remove this. The preprocessor will replace this and the builtin call will never make it to the front end. | |
clang/lib/Basic/Targets/PPC.cpp | ||
238 | I don't see a compelling reason to have this. Users that want this functionality in new code (that doesn't already use __cmplxl) can simply use __builtin_complex. | |
clang/test/CodeGen/builtins-ppc-xlcompat-complex.c | ||
45 | We really only need this test case and we should be able to just add it to one of the existing XL-compat clang test cases. | |
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-complex-32bit-only.ll | ||
1 | I don't think we need the back end tests. No new IR is produced in this patch. |
clang/test/CodeGen/builtins-ppc-xlcompat-complex.c | ||
---|---|---|
35 | I think it would probably be better not to hardcode the variable names in the tests. |
Removed backend tests, removed some uneeded definitions,
updated frontend test with regex for variable names.
clang/test/CodeGen/builtins-ppc-xlcompat-complex.c | ||
---|---|---|
1 | it's not required, but removes a lot of the extra load and stores that make the test cases longer unnecessarily. I can change it to O1 if preferred. |
clang/test/CodeGen/builtins-ppc-xlcompat-complex.c | ||
---|---|---|
45 | As suggest above, can we add the test case __cmplxl to one of the existing clang test file builtins-ppc-xlcompat-cmplx.c? You can auto generate the CHECKS using utils/update_cc_test_checks.py to avoid hardcoding the variable names. |
clang/test/CodeGen/builtins-ppc-xlcompat-complex.c | ||
---|---|---|
1 | I prefer that front end tests should test what the front end does. The front end does not perform optimizations, the optimizer does. So the front end tests should not include optimization options (even though I do realize that adding -O<N> reduces the size of the produced code). |
Please remove this. The preprocessor will replace this and the builtin call will never make it to the front end.