[llvm-dev] [GlobalISel] A Proposal for global instruction selection

[Philip Reames via llvm-dev]

On 01/08/2016 09:12 AM, Quentin Colombet via llvm-dev wrote:
>
>> On Jan 8, 2016, at 8:51 AM, Mehdi Amini <mehdi.amini at apple.com 
>> <mailto:mehdi.amini at apple.com>> wrote:
>>
>>>
>>> On Jan 8, 2016, at 1:34 AM, David Chisnall via llvm-dev 
>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>
>>> On 7 Jan 2016, at 19:47, Quentin Colombet <qcolombet at apple.com 
>>> <mailto:qcolombet at apple.com>> wrote:
>>>>
>>>> Indeed, you said that inttoptr instruction is not a no-op on your 
>>>> architecture, whereas the language reference says:
>>>> “The ‘inttoptr‘ instruction converts value to type ty2 by applying 
>>>> either a zero extension or a truncation depending on the size of 
>>>> the integer value. If value is larger than the size of a pointer 
>>>> then a truncation is done. If value is smaller than the size of a 
>>>> pointer then a zero extension is done. If they are the same size, 
>>>> nothing is done (no-op cast).”
>>>>
>>>> The bottom line is that IMHO, if you rely on inttoptr/ptrtoint 
>>>> instructions to do the conversion from fat pointers to plain 
>>>> integers you are abusing the IR.
>>>>
>>>
>>> I believe that this is somewhere where the IR specification needs to 
>>> evolve.  Currently, we have no in-tree architectures where pointers 
>>> are not integers and so that definition is appropriate.  Adding a 
>>> new pair of IR instructions for integer-to-pointer and 
>>> pointer-to-integer conversions and not calling them inttoptr / 
>>> ptrtoint is likely to be far more confusing.
>>
>> I think this would deserve its own RFC email thread.
>
> +1
FYI, we need something very similar for GC purposes and are going to 
make a proposal along these lines within the next week or two.  We not 
yet to the point of having a "final" proposal, but we're planning on 
starting with some initial experimental support, prototyping on ToT, and 
evolving the spec language as we need to. Details to follow separately.

David, you and I should probably talk offline to make sure what we're 
thinking about works for you as well.
>
> Q.
>>
>> —
>> Mehdi
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160108/cf5c4107/attachment.html>