[llvm-bugs] [Bug 45479] clang constant-folds away runtime test of stack alignment

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45479

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
                 CC|                            |rnk at google.com
             Status|NEW                         |RESOLVED

--- Comment #3 from Reid Kleckner <rnk at google.com> ---
The issue is the spin. Here's a similar example, no inline asm, just an opaque
call:

bool cond();
[[gnu::noinline, gnu::noreturn]] static void spin() {
  while (1)
    ;
}
[[gnu::noreturn]] void crash();
int stuff() {
  if (cond()) {
    crash();
  }
  spin();
}

C++ has some standardese about a forward progress guarantee. This sequence of
IR passes will remove the call to spin, propagate the unreachable backwards,
and eliminate the conditional branch:

opt -functionattrs -instcombine -simplifycfg -S

1. function attrs will deduce that spin is "readnone": it has no side effects,
does nothing
2. instcombine will delete the call because the function call produces no value
and it has no side effects
3. simplifycfg will eliminate the conditional branch to unreachable

To fix the problem, do something (anything) in the spin loop: empty asm,
volatile load, anything the C++ standard considers observable.

There is some bug about teaching LLVM not to assume that the source language
has this forward progress guarantee (for Rust etc), but as far as I know it has
not yet been implemented.

>From a C++ perspective, I believe this is working-as-intended: it is legal to
delete `while (1);`. Not that LLVM sets out to do that, it just happens as a
consequence of other desirable cleanup passes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200408/2be57d72/attachment-0001.html>