This is an archive of the discontinued LLVM Phabricator instance.

Avoid emitting unreachable SP adjustments after `throw`
AcceptedPublic

Authored by rnk on Mar 5 2020, 3:49 PM.

Details

Summary

In 172eee9c, we tried to avoid these by modelling the callee as
internally resetting the stack pointer.

However, for the majority of functions with reserved stack frames, this
would lead LLVM to emit extra SP adjustments to undo the callee's
internal adjustment. This lead us to fix the problem further on down the
pipeline in eliminateCallFramePseudoInstr. In 5b79e603d3b7a2994, I added
use a heuristic to try to detect when the adjustment would be
unreachable.

This heuristic is imperfect, and when exception handling is involved, it
fails to fire. The new test is an example of this. Simply throwing an
exception with an active cleanup emits dead SP adjustments after the
throw. Not only are they dead, but if they were executed, they would be
incorrect, so they are confusing.

This change essentially reverts 172eee9c and makes the 5b79e603d3b7a2994
heuristic responsible for preventing unreachable stack adjustments. This
means we may emit unreachable stack adjustments for functions using EH
with unreserved call frames, but that is not very many these days. Back
in 2016 when this change was added, we were focused on 32-bit, which we
observed to have fewer reserved frames.

Fixes PR45064

Diff Detail

Event Timeline

rnk created this revision.Mar 5 2020, 3:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2020, 3:49 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
hans accepted this revision.Mar 6 2020, 5:19 AM
This revision is now accepted and ready to land.Mar 6 2020, 5:19 AM
This revision was automatically updated to reflect the committed changes.
vitalybuka reopened this revision.Mar 17 2020, 2:37 PM
vitalybuka added a subscriber: vitalybuka.

This patch breaks windows bot http://lab.llvm.org:8011/builders/sanitizer-windows/builds/59930

FAIL: AddressSanitizer-x86_64-windows :: TestCases/intercept-rethrow-exception.cpp (585 of 651)
******************** TEST 'AddressSanitizer-x86_64-windows :: TestCases/intercept-rethrow-exception.cpp' FAILED ********************
Script:
--
: 'RUN: at line 4';      C:/b/slave/sanitizer-windows/build/stage1/./bin/clang.exe  -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -gcodeview -gcolumn-info    -fexceptions -O0 C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\test\asan\TestCases\intercept-rethrow-exception.cpp -o C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\intercept-rethrow-exception.cpp.tmp
: 'RUN: at line 5';    C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\intercept-rethrow-exception.cpp.tmp
--
Exit Code: 255

Command Output (stdout):
--
$ ":" "RUN: at line 4"
$ "C:/b/slave/sanitizer-windows/build/stage1/./bin/clang.exe" "-fsanitize=address" "-mno-omit-leaf-frame-pointer" "-fno-omit-frame-pointer" "-fno-optimize-sibling-calls" "-gline-tables-only" "-gcodeview" "-gcolumn-info" "-fexceptions" "-O0" "C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\test\asan\TestCases\intercept-rethrow-exception.cpp" "-o" "C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\intercept-rethrow-exception.cpp.tmp"
# command output:
   Creating library C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\intercept-rethrow-exception.cpp.lib and object C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\intercept-rethrow-exception.cpp.exp


$ ":" "RUN: at line 5"
$ "C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\intercept-rethrow-exception.cpp.tmp"
note: command had no output on stdout or stderr
error: command failed with exit status: 255
This revision is now accepted and ready to land.Mar 17 2020, 2:37 PM
thakis added a subscriber: thakis.Mar 17 2020, 5:50 PM

Amy bisected https://bugs.chromium.org/p/chromium/issues/detail?id=1062021 down to this. Not clear if that's a compiler bug or some ODR bug like last time, but it's probably good to limit the amount of breakage on trunk.

Somehow forgot to mention the most important bit: I've reverted this in 4e0fe038f438ae1679eae9e156e1f248595b2373 for now.