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

[Sanjoy Das via llvm-dev]

Hi Daniel,

Daniel Berlin wrote:
 >     However, I didn't quite understand your point about may-throw -- how
 >     is may-throw different from a generic side-effect (volatile store,
 >     syscall etc.)?  All of those can't be hoisted or sunk -- we have to
 >     make sure that they execute in semantically the same conditions that
 >     they did in the original program.
 >
 > may-throw is, AFAIK, worse. They act as barriers to sinking *other
 > things*. You cannot sink a store past a may-throw, or hoist a load above
 > them.  You can't optimize stores across them either:

Don't we have the same problems for "exit(0)" and "while(true) {
*volatile_ptr = 42; }" too?  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) {...}").

-- Sanjoy

 > See:
 > [PATCH] D21007: DSE: Don't remove stores made live by a call which 
unwinds.
 > for the latter
 >
 > [llvm] r270828 - [MergedLoadStoreMotion] Don't transform across
 > may-throw calls
 > for the former.
 >
 > "It is unsafe to hoist a load before a function call which maythrow, the
 > throw might prevent a pointer dereference.
 >
 > Likewise, it is unsafe to sink a store after a call which maythrow.
 > The caller might be able to observe the difference."
 >
 > This then leads to the problem i mentioned - because the may-throwness
 > is not expressed at the bb level (or in the CFG, by having the call end
 > the block, or at the least, a fake abnormal CFG edge), everything has to
 > go checking every instruction along the entire path they want to hoist,
 > whereas hoisting is normally just a simple dataflow problem with BB
 > level properties :)
 >
 >
 >