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

[Sanjoy Das via llvm-dev]

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

?

 >
 >
 > 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 :)
 >
 >