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

[Daniel Berlin via llvm-dev]

On Fri, Jul 15, 2016 at 4:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> On Fri, Jul 15, 2016 at 4:00 PM, Andrew Trick <atrick at apple.com> wrote:
>
>>
>> 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.
>>
>> Nobody is looking to change that necessarily, or at least i'm not, only
> to make the impact not "correctness requires N^2 algorithms or other things
> that *already* are slowing down the compiler"
>


Though, just as an aside, i will admit i find the design decision strange.

GCC's design decision is one where nothing has to explicitly care about
implicit early exits to get correct answers about sinking/hoisting (they
won't hoist because the predecessor will have multiple successors, they
won't sink because the current block will have multiple successors. Even
PRE and PDE will get this right by default).

LLVM's design decision is one where everything has to explicitly care about
implicit early exits to get correct answers (and not to harp too much, but
"not everything does", years later).  If they don't, they will get wrong
answers.

Most of LLVM's design tradeoffs are in the other direction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/aabfd358/attachment.html>