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

Ciao,

Duncan.

PS: DwarfEHPrepare currently doesn't simplify selectors (by making sure that
they are always in a landing pad), but it should, and will one day when I get
round to it*

* As the song says "Tomorrow, tommorow, it's only a day away!" :)