These intrinsics expand to a variable number of instructions so just like in ISelLowering.cpp we use custom code to deal with them.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM with test nit.
llvm/test/CodeGen/AArch64/GlobalISel/select-frameaddr.ll | ||
---|---|---|
2 | If you're going to use an llc test can you add -global-isel-abort=1 -verify-machineinstrs too. |
llvm/test/CodeGen/AArch64/GlobalISel/select-frameaddr.ll | ||
---|---|---|
2 | s/llc/.ll |
llvm/lib/Target/AArch64/AArch64InstructionSelector.cpp | ||
---|---|---|
4134 | Should backends be directly consuming intrinsics like this? I would expect these to be lowered earlier, and select to never deal with a generic intrinsic |
llvm/lib/Target/AArch64/AArch64InstructionSelector.cpp | ||
---|---|---|
4134 | What else could these be lowered to? |
llvm/lib/Target/AArch64/AArch64InstructionSelector.cpp | ||
---|---|---|
4134 | You could probably just about expand everything in terms of @llvm.frameaddress(i32 0), but it would be pretty target-specific and not terribly efficient for @llvm.returnaddress(i32 0). |
reverted due to EXPENSIVE_CHECKS fails: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu/builds/1917
Apologies I've bisected an AArch64 sanitiser buildbot failure down to revision 2e39ea726e9cee20060892705164760229e0cb0b
Revert "Revert rG6078f2fedcac5797ac39ee5ef3fd7a35ef1202d5 - "[AArch64][GlobalISel]: Support @llvm.{return,frame}address selection.""
This first started failing http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/8015 with fail mails likely suppressed due to a previous failing build.
When I run the test manually I get the output:
UNCHANGED 'abcdef' EMPTY '' PARTIAL '0x4c3' FIRST_FORMAT 0x4c3694 (/home/peter.smith/llvm/repos/builda64/projects/compiler-rt/test/sanitizer_common/asan-a SECOND_FORMAT FUNC:<null> LINE:0 FILE:<null> LONG_FORMAT LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO GLOBAL: <null> <null>:0
Where the <null> LINE:0: File:<null> are supposed to be // CHECK: SECOND_FORMAT FUNC:main LINE:[[@LINE+1]] FILE:symbolize_pc.cpp
It looks like the symboliser is no longer able to find the function.
The test is run at -O0 so this will get global-isel on AArch64.
Can you take a look?
Sorry, I missed this email. I'll take a look and do a quick fix if I can (don't have access to a linux machine) or revert if it'll take longer.
Should backends be directly consuming intrinsics like this? I would expect these to be lowered earlier, and select to never deal with a generic intrinsic