llvm dev - Jul 2016 - RFC: Strong GC References in LLVM

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> Cc: "Daniel Berlin" <dberlin at dberlin.org>,
"llvm-dev"
> <llvm-dev at lists.llvm.org>, "Joseph Tremoulet"
> <jotrem at microsoft.com>, "Oscar Blumberg"
> <oscar.blumberg at normalesup.org>, "Chandler Carruth"
> <chandlerc at gmail.com>, "Nick Lewycky" <nlewycky at
google.com>, "Hal
> Finkel" <hfinkel at anl.gov>, "Philip Reames"
> <listmail at philipreames.com>, "Manuel Jacob" <me at
manueljacob.de>,
> "Eli Friedman" <eli.friedman at gmail.com>, "David
Majnemer"
> <david.majnemer at gmail.com>
> Sent: Friday, July 15, 2016 6:00:12 PM
> Subject: Re: RFC: Strong GC References in LLVM
> > On Jul 15, 2016, at 3:38 PM, Sanjoy Das <
> > sanjoy at playingwithpointers.com > wrote:
> 
> > > Note that this is also necessary to makes post-dominance correct
> > > (but we
> 
> > > already do it in most cases, but i think there are still bugs
> > > open
> > > about
> 
> > > correctness)
> 
> > Yeah, right now in LLVM we cannot rely on post-dominance to
> > conclude
> 
> > "guaranteed to execute" which isn't ideal. There's
at least one
> > place
> 
> > I know where a more precise post-dominance could be used. :)
> 
> I completely understand the philosophical criticism, but
> - LLVM clearly made the decision/tradeoff to allow implicit early
> exits, and I’m pretty certain that will never change.
Why? A decision was made to give pointers types, and we've decided to change
that. It is not clear to me that the decision to allow implicit early exits was,
in retrospect, optimal. I think it is completely healthy for the project to
reevaluate these kinds of decisions. We now have many years of experience, bug
reports, and we should have a good ability to evaluate the compile-time impact
of a potential change.

-Hal 
> - LLVM made the decision/tradeoff not to maintain a postdom tree
> throughout most of the pass pipeline
> - Fundamentally, you don’t really lose anything. It’s an easy
> analysis to find the exit points and mark blocks. Doing a CFG walk
> instead of a PostDom walk is typically not such a big deal.
> The fundamental problem relevant to Precise GCRef is that the
> dependence between program conditions and loads can’t be expressed.
> I often overload the term “control dependence” here. When I say a
> load is control dependent on a branch, I don’t mean that the load’s
> block is classically control dependent on the branch, I mean that
> the load is illegal to speculate above the branch. Yes they are two
> different things, but I don’t have a better term to use for that
> dependence information.
> -Andy
-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/5692b45a/attachment-0001.html>

> On Jul 15, 2016, at 4:48 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> Why? A decision was made to give pointers types, and we've decided to
change that. It is not clear to me that the decision to allow implicit early
exits was, in retrospect, optimal. I think it is completely healthy for the
project to reevaluate these kinds of decisions. We now have many years of
experience, bug reports, and we should have a good ability to evaluate the
compile-time impact of a potential change.

Let me rephrase: It didn’t seem to me like the fundamental problem we were up
against in this discussion, and it’s definitely very difficult to change given
the burden it would place on intrinsics.

FWIW, for a long time I was a very strong proponent of explicit control flow
because I like making it easy to reason about CFG transforms and code motion.
But I gradually came around to realize it’s a legitimate design either way. In
some ways it works well not to have a CFG edge for exits where it’s illegal to
insert code. I think LLVM passes have also been biased toward algorithms that
scale in the number of blocks.

That’s all I really have to say about it.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/5f4133bd/attachment.html>

On Fri, Jul 15, 2016 at 5:25 PM, Andrew Trick <atrick at apple.com> wrote:
>
> On Jul 15, 2016, at 4:48 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> Why? A decision was made to give pointers types, and we've decided to
> change that. It is not clear to me that the decision to allow implicit
> early exits was, in retrospect, optimal. I think it is completely healthy
> for the project to reevaluate these kinds of decisions. We now have many
> years of experience, bug reports, and we should have a good ability to
> evaluate the compile-time impact of a potential change.
>
>
> Let me rephrase: It didn’t seem to me like the fundamental problem we were
> up against in this discussion, and it’s definitely very difficult to change
> given the burden it would place on intrinsics.
>
>
Yes, this discussion has gone a bit off track, which i will apologize for.

> FWIW, for a long time I was a very strong proponent of explicit control
> flow because I like making it easy to reason about CFG transforms and code
> motion. But I gradually came around to realize it’s a legitimate design
> either way. In some ways it works well not to have a CFG edge for exits
> where it’s illegal to insert code.
>
> I think LLVM passes have also been biased toward algorithms that scale in
> the number of blocks.
>
If this scaling is a design goal that's really interesting. Most of the
memory opt and code motion algorithms i've worked on in LLVM are
block/instruction-capped in the same way (and most have lower caps than GCC
due to compile time impact on llvm).
There certainly was a time when that wasn't true (i remember back in the
day :P), but it's no longer true.

Of course, I don't actually think either design necessarily makes scaling
easier or harder, that's just "the state of the world".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/9adab27c/attachment-0001.html>