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

[Duncan Sands]

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

Ciao,

Duncan.

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