[llvm-dev] RFC: Strong GC References in LLVM
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 21 10:30:17 PDT 2016
On Thu, Jul 21, 2016 at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 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>
>> 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:
> The list is almost certainly larger than this, this was a pretty trivial
> grep and examination.
> (and doesn't take into account bugs, etc)
(Note, this list is stuff in the Scalar directory only. Everything in
Vectorize would n eed it, etc)
And in case folks want more evidence that reasonable llvm developers need
something that just gives easy and right answers, see
https://reviews.llvm.org/D22547 from just yesterday :)
To move this along, i will go build the analysis (I already have it mostly
done, actually). If someone updates our docs to make this stuff clear and
obvious, that would be wonderful :)
The analysis currently computes, internally, for a given BB:
EarliestLoadHoistBarrier (used to see if you can move something out of a
LatestLoadHoistBarrier (used to find the latest safe insertion point in a
block, if any)
(stores are maythrow dependent, loads are
I'm still coming up with the external API, the users all want to know
1. Can i move a load up out of this block to a direct predecessor
2. Can i move a store down out of this block to a direct successor
GVN's current load PRE is complex to get "right" from it's current
standpoint, the APi that will provide the easiest way to fix it will be:
3. What is the latest insertion point in a block for a load, if it is safe
(IE the block does not end in an instruction you cannot move the load
Nothing is doing global store sinking right now that i see, so nothing
needs the analogous store api.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev