[PowerPC] Handle CALL_RM like CALL for 32-bit ELF #72758
Conversation
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
If a function call has the strictfp attribute, its opcode changes from CALL to CALL_RM. If the call uses the secure PLT for 32-bit ELF, then it must getGlobalBaseReg() to set r30.
kernigh
force-pushed
the
kernigh-ppc32-rm
branch
from
d497ab3 to
b34f3c3
Compare
Handle CALL_RM like CALL for 32-bit ELF. If a function call has the strictfp attribute, its opcode changes from CALL to CALL_RM. If a call uses the secure PLT, then it must getGlobalBaseReg() to set r30. After I rebuilt xenocara/lib/pixman with this change, Xorg stopped crashing on my macppc. pixman uses cc -ftrapping-math which puts strictfp on each function call. llvm/llvm-project#72758 ok jca@ tobhe@ deraadt@
|
Ping. |
|
Ping. |
| @@ -0,0 +1,21 @@ | |||
| ; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu -mattr=+secure-plt -relocation-model=pic | FileCheck %s | |||
There was a problem hiding this comment.
Can we use auto generate script for it?
|
@kernigh Ping. |
| } break; | ||
| case PPCISD::CALL: { | ||
| case PPCISD::CALL: | ||
| case PPCISD::CALL_RM: { |
There was a problem hiding this comment.
Are your targeting this for SPE? SPE should have no floating point instructions? So round mode should not be a concern? For SPE, we may stop generate CALL_RM where it is generated. Note that CALL_RM performs worse than normal CALL even after instruction selection. They are selected to different instructions.
If for other PPC32 targets, the fix looks reasonable to me.
There was a problem hiding this comment.
Are your targeting this for SPE?
This is not for SPE.
chenzheng1030
left a comment
chenzheng1030
left a comment
There was a problem hiding this comment.
LGTM as long as @ecnelises's comment about the LIT case is addressed.
Handle CALL_RM like CALL for 32-bit ELF. If a function call has the strictfp attribute, its opcode changes from CALL to CALL_RM. If a call uses the secure PLT, then it must getGlobalBaseReg() to set r30. After I rebuilt xenocara/lib/pixman with this change, Xorg stopped crashing on my macppc. pixman uses cc -ftrapping-math which puts strictfp on each function call. llvm#72758 ok jca@ tobhe@ deraadt@
|
It would be nice to get this in. |
Please let us know if need us to commit this pr. @kernigh |
He does, but there was the issue of the test case being updated. |
https://reviews.llvm.org/D111433 introduced PPCISD::CALL_RM for -frounding-math. -msecure-plt -frounding-math {-fpic,-fPIC} codegen for PPC32 became incorrect when a function contains function calls but no global variable references (GlobalBaseReg). As reported by @q66 , musl/src/dirent/closedir.c implements such a function, which is miscompiled. PPCISD::CALL has custom logic to set up the base register (https://reviews.llvm.org/D42112). Add an extra case for CALL_RM. While here, improve the test to * actually test `case PPCISD::CALL`: we need a non-leaf function that doesn't access global variables (global variables lead to GlobalBaseReg, which call `getGlobalBaseReg()` as well). * test `ExternalSymbolSDNode` with a memset. Supersedes: #72758 Pull Request: #121281
4 participants
If a function call has the strictfp attribute, its opcode changes from CALL to CALL_RM. If the call uses the secure PLT for 32-bit ELF, then it must getGlobalBaseReg() to set r30.
This fixes a bug that I described in (OpenBSD) macppc clang-16 -ftrapping-math crashes Xorg. The short version is that clang -ftrapping-math broke code like
int main(void) { time(NULL); }by forgetting to set r30 before using the secure PLT.