[llvm-commits] [llvm] r94046 - /llvm/trunk/lib/CodeGen/DwarfEHPrepare.cpp

[Jim Grosbach]

On Jan 21, 2010, at 9:55 AM, Duncan Sands wrote:

> Hi Jim,
> 
>>>> I totally agree it's a bit cringe-inducing. It's necessitated by the self-described hack in SelectionDAGISel::SelectAllBasicBlocks()  which tries to deal with eh.selectors that end up in blocks not an immediate unwind successor to an invoke. A hack has begat another hack, essentially.
>>>> I spent a good while trying to think of better options, but didn't come up with anything better. The best alternative I came up with was to remove the invokes, selectors, et.al. completely in the SjLj pass, but that would require a re-implementation all of the EH mechanisms that come afterwards to support the exception tables. While I'm not sure that wouldn't be a good thing in the long term, it's also a much larger project.
>>> one thing I don't understand is why SjLj lowering is run before DwarfEHPrepare,
>>> and not after.  The role of DwarfEHPrepare is to normalize and simplify eh stuff
>>> so life is easy for the code generators that come after.  Surely this simplified
>>> input is what should be fed to SjLj lowering (I confess I never looked at what
>>> the SjLj lowering stuff does...).
>>> 
>> Things get even trickier if the order is reversed, and another aspect of the same issue. Specifically, SjLj needs to split critical edges at the invokes. When a landing pad is shared between multiple invokes and also has a normal edge coming in (from inlining or whatever), the combination of the edge splitting and normalization causes the selector to be more than a single block away from the landing pad, and SelectAllBasicBlocks() can't handle that.
> 
> so if DwarfEHPrepare sorted out selectors (i.e. made sure they are always in
> landing pads[*]) your problems would be solved?  (DEP already makes sure that
> only unwind branches of invokes end up at landing pads, and no normal edges).
> 

It's very probable that would address the problems that spawned this patch, yes. It would also allow us to get rid of the CopyCatchInfo stuff in SelectAllBasicBlocks() and the lost/found catch info bits, which would be very nice.

> Ciao,
> 
> Duncan.
> 
> [*] Definition of a landing pad: a basic block which is branched to by the
> unwind branch of at least one invoke.