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

[Daniel Berlin via llvm-dev]

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>