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

> On Jan 8, 2016, at 1:34 AM, David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 7 Jan 2016, at 19:47, Quentin Colombet <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.

— 
Mehdi

> On Jan 8, 2016, at 8:51 AM, Mehdi Amini <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> wrote:
>> 
>> On 7 Jan 2016, at 19:47, Quentin Colombet <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

Q.
> 
> — 
> Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160108/792ab1b5/attachment.html>

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>