[llvm-commits] [PATCH] Revised LandingPadInst Patch

Bill Wendling wendling at apple.com
Tue Aug 9 11:25:53 PDT 2011


On Aug 9, 2011, at 2:32 AM, Duncan Sands wrote:

> Hi Bill,
> 
>>> 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.
> 
> I think you misunderstood.  I meant something like this:
> 
> @_ZTIc = external constant i8*
> @_ZTId = external constant i8*
> @_ZTIPKc = external constant i8*
> 
> %exn = landingpad {i8*, i32} personality i32 (...)* @__gxx_personality_v0
>       cleanup
>       i8** @_ZTIc          ; catch because global variable
>       [0 x i8**] []        ; (empty) filter because constant array
>       i8** @_ZTIc          ; catch because global variable
>       [0 x i8**] []        ; (empty) filter because constant array
>       i8** @_ZTId          ; catch because global variable
>       [2 x i8**] [ i8** @_ZTIPKc, i8** @_ZTId ] ; filter because constant array
> 
> Ciao, Duncan.

Ah! I think I understand. So it's not so much that the arrays would be splatted out into the OperandList, but that they would be referenced from there (or something).

BTW, care must be taken. An empty filter has a specific meaning in this scheme: it's equivalent to a "throw()" in C++.

-bw






More information about the llvm-commits mailing list