[llvm-commits] [PATCH] Revised LandingPadInst Patch

[Duncan Sands]

Hi Bill,

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

I meant the operand really being a null pointer, not a constant of type i8* with
a value of null (the C++ catch-all).

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

That's pretty similar to how the eh.selector intrinsic did it, see
http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector

I don't think there was any random access of the eh.selector operands.  For
codegen you traverse them.  For inlining you will just traverse them too right?

An alternative is to have: for a catch, an operand which is a (bitcast) global
or null*; for a filter, an operand which is a constant array, each element of
which is a (bitcast) global or null*.  Thus each clause would only take up one
operand.

Ciao, Duncan.