[PATCH] Fix WinEHPrepare bug with multiple catch handlers

[Andy Kaylor]

That's pretty much why I put this up for review.  I'm not entirely happy with this solution to the original problem (referencing a loaded EH selector value in a block whose cloning director didn't see it being loaded).  The problem arises from the decision not to start cloning at the original landing pad block.  The mapLandingPadUsers code tries to handle this sort of thing by looking at all the places where the original values are stored, but if there's an efficient way to find all of the places where it is loaded again, I'm not aware of it.

The way that the cloning works, the first time we're forced to deal with the unrecognized %sel value would be in the materializeValueFor() method and by then it's too late (unless we shared the mapped landing pad values with the materializer and that seems very ugly).

Of course, if we want to be entirely bullet-proof the problem is even worse.  You can imagine all sorts of ways that a selector value could be manipulated such that the handler cloning code isn't even looking at a load of the original stored value.  In practice, the only things that I would ever expect to happen to the selector value are (1) extract from the aggregate, (2) insert into another aggregate value, (3) stored to a memory location, (4) loaded from a memory location, (5) compared with a result of llvm.eh.typeid.for().  I'm just not sure it's reasonable to impose this as a limitation.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8682

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/