[LLVMdev] struct returns
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
>>> pointers, or can it be safely ignored when lowering loads, stores,
>>> 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
More information about the llvm-dev