[llvm-commits] [PATCH] Revised LandingPadInst Patch

[Bill Wendling]

On Aug 9, 2011, at 1:59 AM, Duncan Sands wrote:


>> 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
> 
Similar, but not the same. :-) It's more explicit (at least to me) where one clause leaves off and the others take over.

> 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?
> 
Yeah. I don't think it would be a huge problem, to be honest. Just something for me to worry about is all. :-)

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


The "OperandList" setup for the Instructions is rather complex as it is. Having two or more OperandLists (one list for each 'filter' array) gets very complex very quickly. And we want an OperandList-like data structure so that it can track uses of the LLVM IR objects.

-bw