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

[Bill Wendling]

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.

-bw