[llvm] r179569 - We are not able to bitcast a pointer to an integral value.
Bill Wendling
wendling at apple.com
Thu Apr 18 16:39:18 PDT 2013
On Apr 18, 2013, at 2:32 PM, Bill Wendling <wendling at apple.com> wrote:
> On Apr 17, 2013, at 10:22 PM, Duncan Sands <baldrick at free.fr> wrote:
>
>> Hi Bill,
>>
>> On 18/04/13 02:06, Bill Wendling wrote:
>>> On Apr 16, 2013, at 9:42 AM, Duncan Sands <baldrick at free.fr> wrote:
>>>
>>>> Hi Bill,
>>>>
>>>> On 16/04/13 00:33, Bill Wendling wrote:
>>>>> Author: void
>>>>> Date: Mon Apr 15 17:33:50 2013
>>>>> New Revision: 179569
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=179569&view=rev
>>>>> Log:
>>>>> We are not able to bitcast a pointer to an integral value.
>>>>>
>>>>> Two return types are not equivalent if one is a pointer and the other is an
>>>>> integral. This is because we cannot bitcast a pointer to an integral value.
>>>>> PR15185
>>>>
>>>> you can always ptrtoint it. I thought the idea of mergefunctions was to
>>>> ignore types, and consider two values the same if they have the same bits,
>>>> regardless of whether they are pointers, integers, floats or whatever. If
>>>> so, it seems a pity to suddenly decide that type differences matter.
>>>>
>>> It wasn't me who decided that, but the bitcast instruction. :-) It expressly prohibits casting a pointer to an integer value.
>>
>> I meant something a bit different: rather than observe that one function has
>> an integer return type and the other a pointer return type and decide that the
>> functions are not equivalent (the fix in your patch), you could instead leave
>> the old logic for function equivalence (say that they are equivalent), and use
>> a ptrtoint in the place that converts the pointer return result to the integer
>> return result. I.e. rather than just always generate a bitcast, generate one
>> of: bitcast, ptrtoint or inttoptr as appropriate.
>>
> I realized that. :-) It's not a bad idea. I'll think about it.
>
Done: r179817.
-bw
More information about the llvm-commits
mailing list