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

[Daniel Berlin via llvm-dev]

On Thu, Jul 21, 2016 at 9:26 AM, Andrew Trick <atrick at apple.com> wrote:

>
> On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com>
> wrote:
>
> Joining in very late, but the tangent here has been interesting (if rather
> OT for the original thread).
>
> I agree with Danny that we might want to take a close look at how we model
> things like maythrow calls, no return, and other implicit control flow.
> I'm not convinced that moving to a pure explicit model is the right idea
> because we get a lot of gain in practice from being able to reason about
> what are essentially a limited form of extended basic blocks.  I would
> welcome a design discussion about this, preferably in person, but also
> don't want to block any current (or future honestly) work on this until we
> have a reasonable firm plan of action.
>
> One idea would be to explicitly acknowledge that our "basic blocks" are
> actually "extended basic blocks" with internal exits due to exception
> propagation, noreturn, and (recently) guards.  I could see a couple of
> implementation strategies here:
> 1) Extend BasicBlock to explicitly track potential early exiting
> instructions.  This would probably have to be conservative so that things
> like nothrow inference aren't required to update all callers in one go.
> 2) Conservative assume that BasicBlock has an unknown number of early
> exiting instructions and write an analysis pass which answers questions
> about where those early exits are.  Any pass which does code motion would
> require this analysis.  (This is essentially the principled version of our
> current hacks.)
>
>
> This analysis can be lazy/incremental. Most passes only do “safe”
> speculation and code sinking without side effects.
>

While I agree it can be lazy, and should be an analysis, i'm, again, really
not sure which passes you are thinking about here that do code
sinking/speculation that won't need it.

Here's the list definitely needing it right now:
GVN
GVNHoist
LICM
LoadCombine
LoopReroll
LoopUnswitch
LoopVersioningLICM
MemCpyOptimizer
MergedLoadStoreMotion
Sink

The list is almost certainly larger than this, this was a pretty trivial
grep and examination.
(and doesn't take into account bugs, etc)


It would be nice to know which passes, specifically, you are thinking of
when you say "most" :)



> They don’t need to run the analysis.
>


> Thanks Philip. I forgot to mention that LLVM passes historically have
> taken advantage of implicit extended basic blocks (ISel) and were never
> improved to handle general EBBs. It took years for loop opts to finally
> handle early exits well.
> -Andy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/37120af8/attachment.html>