[llvm-commits] [PATCH] Revised LandingPadInst Patch

[Bill Wendling]

On Aug 9, 2011, at 12:27 AM, Duncan Sands wrote:

> Hi Bill,
> 
>> This is the next iteration of the landingpad instruction patch. It incorporates the feedback from Chris and Duncan. Notably, the values that are stored are now "Value*"s instead of "Function*" or "Constant*". Duncan pointed out that bitcasts can get in the way of things.
> 
> they are constant bitcasts (ConstExpr), so Constant* is fine.  I think Constant*
> is better than Value*.
> 
Okay. I'll make that change before committing it. :)

>> The LandingPadInst has this ugly wart on it, namely the "Index" structure that Chris pointed out. I need a way to indicate the clause type for an object in the OperandList, it's index into that list, and how many "types" are associated with that. This is because of inlining. When we inline things, we are going to append the clauses to this list. And they need to be in the correct order so that the exception tables are generated correctly.
> 
> If you only had (say) filters and no catches, then you could use a null operand
> to indicate the end of a sequence of filters, so you would have operands like
> this:
> not-null ... not-null null not-null ... not-null null
> \___  filter1  ___/         \___  filter2  ___/
> But you have both catches and filters, so need something more clever...  I
> didn't come up with anything yet :)
> 

Also, I don't want to specify a type that may be used as a real value in the list. (i8* null is of course the "catchall" indicator for C++.) Maybe I could encode the clause type, the number of elements, and the elements like this:

OperandList:

OperandList[1] = ConstantInt::get(LandingPadInst::Catch)
OperandList[2] = <the Constant* that points to the catch's catch type>
OperandList[3] = ConstantInt::get(LandingPadInst::Filter)
OperandList[4] = ConstantInt::get(<number of Filter "types">)
OperandList[5] = <filter type 1>
 …
OperandList[5+n] = <filter type n>

Etc? That way there's no need for the "Index" structure. The only problem is that random access of variables no longer has O(1) complexity. That may not be a factor, depending on how often one needs to access the clauses in a random fashion...

-bw