[all-commits] [llvm/llvm-project] dd76d9: [llvm][ARM] Correct the properties of trap instruc...

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dd76d9b1bbe0a4ca5375604bc941bb422de55ed6
      https://github.com/llvm/llvm-project/commit/dd76d9b1bbe0a4ca5375604bc941bb422de55ed6
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2024-10-23 (Wed, 23 Oct 2024)

  Changed paths:
    M llvm/lib/Target/ARM/ARMInstrInfo.td
    M llvm/lib/Target/ARM/ARMInstrThumb.td
    M llvm/test/CodeGen/ARM/trap.ll

  Log Message:
  -----------
  [llvm][ARM] Correct the properties of trap instructions (#113287)

Fixes #113154

The encodings used for llvm.trap() on ARM were all marked as barriers
and terminators. This lead to stack frame destroy code being inserted
before the trap if the trap was the last thing in the function and it
had no return statement.
```
void fn() {
  volatile int i = 0;
  __builtin_trap();
}
```
Produced:
```
fn:
        push    {r11, lr}   << stack frame create
<...>
        mov     sp, r11
        pop     {r11, lr}   << stack frame destroy
        .inst   0xe7ffdefe  << trap
        bx      lr
```
All the other targets don't mark them this way, instead they mark them
with isTrap. I've changed ARM to do this, which fixes the code
generation:
```
fn:
        push    {r11, lr}   << stack frame create
<...>
        .inst   0xe7ffdefe  << trap
        mov     sp, r11
        pop     {r11, lr}   << stack frame destroy
        bx      lr
```
I've updated the existing trap test to force the need for a stack frame,
then check that the instruction immediately after the trap is resetting
the stack pointer.

debugtrap was already working but I've added the same checks for it
anyway.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications