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

[Daniel Berlin via llvm-dev]

On Fri, Jul 15, 2016, 3:38 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> Hi Daniel,
>
> Daniel Berlin wrote:
>  >     /* Add fake edges to the function exit for any non constant and non
>  >          noreturn calls (or noreturn calls with EH/abnormal edges),
>  >          volatile inline assembly in the bitmap of blocks specified by
>  >     BLOCKS
>  >          or to the whole CFG if BLOCKS is zero.
>  >     ...
>  >
>  >          The goal is to expose cases in which entering a basic block
> does
>  >          not imply that all subsequent instructions must be executed.
> */
>  >
>  >
>  > 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. :)
>
>  > For dominance, the dominance relationship for exit blocks a noreturn
>  > blocks reach also changes , though i don't honestly remember if it's
>  > material or not, and i'm a bit lazy to think about it.  But here's an
>  > example:
>  >
>  >
>  > IE given
>  >
>  > A (may-throw)
>  > |
>  > v
>  > B
>  > |
>  > v
>  > C (exit)
>  >
>  >
>  > Here, we have A dominates B dominates C
>  >
>  > So the dominator tree is
>  > A
>  > |
>  > v
>  > B
>  > |
>  > v
>  > C
>  >
>  > Now, if you add an edge from A to C, you have:
>  >
>  > A dominates B
>  > Neither B nor A dominate C (C's idom is somewhere above, so it's in a
>  > sibling tree somewhere).
>
> Not sure I understand this example -- won't C's new idom be A?  The new
> graph is this, right:
>
> A -> C
> A -> B
> B -> C
>
> ?
>

Yes I originally constructed the graph with two blocks with may throw
calls, then simplified it and screwed up. Such is Friday 😀
I noticed right after I sent it and left for the day but not before you
caught it.

>
>  >
>  >
>  > IE
>  >
>  > A    C
>  >   |
>  > B
>  >
>  >
>  > In GCC, there is a single exit block, and it is always empty (returns
>  > are connected to the exit block).
>  > Thus, the above will not prevent an optimization that should otherwise
>  > happen, from happening.
>  >
>  > Because LLVM's exit blocks contain real code, it may
>  >
>  > You can actually get even worse (ie really wrong) situations if the
>  > "exit" blocks somehow have successors, but thankfully we don't have a
>  > case where that happens that i know :)
>  >
>  >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/d1b6a3c2/attachment.html>