[llvm-dev] [GlobalISel] A Proposal for global instruction selection
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 8 14:40:54 PST 2016
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.
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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev