[llvm-dev] RFC: Strong GC References in LLVM
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 15 12:36:57 PDT 2016
On Fri, Jul 15, 2016 at 12:21 PM, Sanjoy Das <sanjoy at playingwithpointers.com
> Hi Daniel,
> Daniel Berlin wrote:
> > As a starting point, LLVM will conservatively not speculate such
> > loads and stores; and will leave open the potential to upstream
> > logic that will have a more precise sense of when these loads
> > stores are safe to speculate.
> > I think you need to define what you mean by control dependence here. If
> > you mean speculation, you should say speculation :)
> Apologies for being non-specific -- this is really just "don't
> > As you describe below, it is not enough to simply not speculate them.
> I'm not sure where I said that?
> > You also are saying you don't want to change the conditions on which
> > they execute.
> > That is very different from speculation.
> If I implied that somehow then I (or the example) was wrong. :)
> We can't speculate these instructions (without special knowledge of
> the GC and the Java type system), and that's it.
> > FWIW: This raises one of the same issues we have now with may-throw,
> > which is that, if all you have is a flag on the instruction, now you
> > have to look at every instruction in every block to know whether a *CFG*
> > transform is correct.
> > That means any pass that wants to just touch the CFG can't do so without
> > also looking at the instruction stream. It will also make a bunch of
> > things currently O(N), O(N^2) (see the sets of patches fixing may-throw
> > places, and extrapolate to more places).
> As I said, I'm only proposing a "don't speculate" flag, so this does
> not (?) apply.
As long as it applies only to the instructions, and they do not act as
"barriers" to hoisting/sinking, then yes, it should not apply.
(In theory it still means things have to look at instructions, but they had
to look at them anyway at that point :P)
> 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:
[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
for the former.
"It is unsafe to hoist a load before a function call which may throw, the
throw might prevent a pointer dereference.
Likewise, it is unsafe to sink a store after a call which may throw.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev