[LLVMdev] struct returns

Dan Gohman gohman at apple.com
Mon Sep 21 11:58:39 PDT 2009

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.


More information about the llvm-dev mailing list