[llvm] r179569 - We are not able to bitcast a pointer to an integral value.

[Bill Wendling]

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