[llvm-dev] RFC: Strong GC References in LLVM

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 15 14:44:02 PDT 2016

Hi Daniel,

Daniel Berlin wrote:
 >     Don't we have the same problems for "exit(0)"
 > This is a noreturn call, so yes, iit has another hidden control
 > flow-side-effect of a slightly different kind. GCC models it as an extra
 > fake edge from the BB containing a noreturn call to the exit block of
 > the function, so that nothing sinks below it by accident.

Just to be clear, it'd have to keep that sort of edge for all call
sites, unless it can prove that the call target does not call exit?

 > I do not believe we do anything special here, so yes, it also has the
 > same general issue as may-throw.
 >     and "while(true) {
 >     *volatile_ptr = 42; }" too?
 > I can move non-volatile stores past volatile stores :)

I meant:

// ptr_a and ptr_b are NoAlias, ptr_a holds 0 to begin with.

   while(true) { store volatile i32 42, i32* %ptr_b }
   store atomic i32 42, i32* %ptr_a

   %val = load atomic i32, i32* %ptr_a
   assert(%val is not 42)  // The store is "guarded" by an inf loop

We can't reorder the store to ptr_a to before the infinite loop.  The
volatile store is there to make the infinite loop well defined.

 > Or did you mean something else?
 >        Both of these are optimization barriers
 >     while still being "nounwind" (i.e. could be legitimately contained in
 >     a nounwind function); though not in exactly the same way as a
 >     may-throw call (e.g. you can DSE across exit(0) and you can sink
 >     non-atomic loads past "while(true) {...}").
 > I do not claim there are not other instances. Noreturn is in fact, a
 > good exampl). But i would also bet they are just as buggy as may-throw
 > was for the same reason, and they would cause the same N^2ness.


 > Essentially, anything that has produces hidden control flow (instead of
 > just depending on hidden control flow) will have this issue.
 > The also are things that any flag/analysis should be able to flag.


-- Sanjoy

More information about the llvm-dev mailing list