[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
eli.friedman at gmail.com
Mon Jun 13 15:17:42 PDT 2011
On Mon, Jun 13, 2011 at 2:56 PM, John McCall <rjmccall at apple.com> wrote:
> On Jun 13, 2011, at 2:23 PM, Andrew Trick wrote:
> On Jun 13, 2011, at 12:29 AM, John McCall wrote:
> On Jun 12, 2011, at 11:24 PM, Bill Wendling wrote:
> On Jun 12, 2011, at 4:40 PM, John McCall wrote:
> On Jun 12, 2011, at 2:14 PM, Cameron Zwarich wrote:
> On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote:
> Hi Sohail,
> Is LLVM expressive enough to represent asynchronous exceptions?
> not currently. The first step in this direction is to get rid of the invoke
> instruction and attach exception handling information to basic blocks. See
> for a discussion.
> Is this really a good idea? Why have a control flow graph if it doesn't
> actually capture control flow? There are lots of compilers for languages
> with more pervasive exceptions that represent them explicitly, e.g. the
> Hotspot server compiler for Java or several ML compilers (where integer
> overflow throws an exception).
> You and Bill seem to be responding to a different question, namely "Is LLVM
> expressive enough to represent synchronous exceptions from non-call
> instructions?" This really has nothing to do with Sohail's question.
> Duncan is quite correct: the only reasonable representation for
> asynchronous exceptions is to attach EH information to basic blocks.
> Placing the EH information on the basic block has the same implications for
> the CFG for both questions.
> Let me make an analogy. We live in Germany. Sohail wants to drive to
> Spain. Duncan told him to go through France. You and Cameron are saying
> that the traffic in France is awful, and some friends who went to Italy
> didn't go through France. I am trying to point out that Italy is not Spain,
> even though they are both on the Mediterranean, and that you have to drive
> through France to get to Spain.
> There is really no alternative to putting EH edges on basic blocks if you're
> going to support preemptive asynchronous exceptions — some random multiply
> that gets hoisted out of a loop has to change exception handlers just in
> case that's where the PC lands during a signal. There isn't much point in
> complaining that doing so muddies the CFG, which is really just an inherent
> fact of handling asynchronous exceptions. That is not true for synchronous
> exceptions; you don't have to abandon the "internally throwing instructions
> are terminators" design at all, you just have to allow more things to be
> No. Duncan suggested that he could hitch a ride with us through France. The
> problem is, we're not driving to Spain at all and there doesn't appear to be
> any place to transfer.
> We have not yet reached a consensus to not go to Spain. I would be fine
> with that outcome, though.
> The point is, you're not going to be able to leverage most of a CFG-based
> optimizing compiler if don't use the CFG to express control flow.
> I don't understand the argument that "the CFG" has to be defined by "certain
> uses by terminator instructions". Unwind edges are inherently a different
> kind of edge because they proceed from within the execution of an
> instruction. Making the edge explicit on each possibly-throwing instruction
> makes it easier to demonstrate that transforms don't change exception
> behavior, in part by making it very awkward to write any transforms on
> "invoking" instructions at all. We don't care right now because all
> throwing instructions are calls and therefore generally optimization
> barriers, modulo inlining / partial inlining / specialization. But that's
> not true of loads and FP operations.
The thing I've never really quite understood with this whole
discussion of attaching an unwind edge to blocks is how this works
with SSA form... how do you write a PHI node that has multiple values
on a given edge?
More information about the llvm-dev