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

[Daniel Berlin via llvm-dev]

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

>
>
> On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <
> sanjoy at playingwithpointers.com> wrote:
>
>> Hi Daniel,
>>
>> Daniel Berlin wrote:
>> >     Don't we have the same problems for "exit(0)"
>> >
>> >
>> > This is a noreturn call, so yes, iit has another hidden control
>> > flow-side-effect of a slightly different kind. GCC models it as an extra
>> > fake edge from the BB containing a noreturn call to the exit block of
>> > the function, so that nothing sinks below it by accident.
>>
>> Just to be clear, it'd have to keep that sort of edge for all call
>> sites, unless it can prove that the call target does not call exit?
>
>
> Yes.
>
> /* 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)

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


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/0ae70ffe/attachment-0001.html>