[LLVMdev] struct returns

[Dan Gohman]

On Sep 21, 2009, at 11:12 AM, Kenneth Uildriks wrote:

>>> It occurs to me that all declarations of a function pointer, and all
>>> bitcasts to a function pointer, could possibly refer to a function
>>> whose signature must be altered by this fix.  Is the function
>>> signature relevant to the SelectionDAG representation of said  
>>> function
>>> pointers, or can it be safely ignored when lowering loads, stores,  
>>> and
>>> bitcasts involving such pointers?
>>
>> No. Fortunately, you don't have to worry about complicated bitcast
>> situations here. There are only two constructs which are affected:
>> function definitions and function calls. And in the case of calls,
>> the only thing that matters is the type of the call operand itself,
>> not what the operand might have been bitcasted from.
>
> What about the type of the ptr-to-function-ptr that the call operand
> was *loaded* from?  This will come up whenever a function pointer is
> stored in callback situations.  If I change the call operand, it won't
> match the element type of the pointer it was loaded from.  Does this
> matter in a SelectionDAG?

No, and it doesn't matter in LLVM IR either. It's a front-end's
responsibility to ensure that the (static) type of the call operand
is compatible with the type of all actual callees that it can call
at runtime.

Dan