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

> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
> On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at apple.com>
wrote:
>> 
>> I must miss something, but I don’t get what is the problem of lower the
pointer to actual integer.
> 
> Pointers, in our architecture, are not integers.
Thanks for the clarifications.

So what you’re saying is that a inttoptr instruction is not a no-op on your
architecture, is that right?
Or it can be a no-op only if the consumer of the pointer values can be done on
the pointer register bank?

Don’t know if that helps, but note that the registers are not typed, they just
have size. The operations are typed.

I am trying to understand the constraint to see how that would fit in the
framework. That being said, anything that you could do in SDag should be
possible as well in the new framework.

Cheers,
-Quentin
> 
> David
>

On 19 Nov 2015, at 18:07, Quentin Colombet <qcolombet at apple.com>
wrote:
> 
> 
>> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
>> 
>> On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at
apple.com> wrote:
>>> 
>>> I must miss something, but I don’t get what is the problem of lower
the pointer to actual integer.
>> 
>> Pointers, in our architecture, are not integers.
> 
> Thanks for the clarifications.
> 
> So what you’re saying is that a inttoptr instruction is not a no-op on your
architecture, is that right?
Correct.
> Or it can be a no-op only if the consumer of the pointer values can be done
on the pointer register bank?
Yes (in some compilation models, we support 64-bit integers as pointers and
256-bit / 128-bit fat pointers, with the integer values being implicitly checked
against a large region identified by one of the fat pointer registers, giving a
coarse-grained sandbox that can communicate with the outside world via bounded
pointers).

We currently have entirely separate fat pointer and integer register banks,
though we’re investigating a mode where we’ll overlay the two on the same
register file (though they’ll likely treat some things as sub-registers.

It also means that address space casts are not a no-op for us, which I believe
is something that we share with some GPU ISAs (e.g. a 32-bit [or 16-bit] local
pointer cast to a 64-bit global address space is not a simple sign/zero
extension and so must be handled differently to an i32 -> i64 translation)
> Don’t know if that helps, but note that the registers are not typed, they
just have size. The operations are typed.
That’s fine, once you’ve assigned values to register banks.  The issue is
ensuring that we’re not throwing away the information that we need to do that
assignment in the translation from LLVM IR to the new machine IR (i.e. which
values are pointers, and which address space they are in).
> I am trying to understand the constraint to see how that would fit in the
framework. That being said, anything that you could do in SDag should be
possible as well in the new framework.
We currently add several new nodes to SDag: INTTOPTR, PTRTOINT, and PTRADD, and
a new iFATPTR MVT.  The last is somewhat problematic, as we really want to have
iFATPTR128 and iFATPTR256 (and, potentially, iFATPTR64 for an IoT/embedded
variant).

David

Having a distinction between integers and pointers preserved into MI 
would be quite useful for garbage collection as well.  We currently have 
a lowering phase (RewriteStatepointsForGC) which effectively rewrites 
operations of references (i.e. managed pointers) so that they can be 
treated as integers throughout the rest of the pipeline.  If we could 
retain the distinction further back through the backend, it would both 
simply a lot of code and likely let us generate better code (spilling, 
etc..) around safepoints.

Philip

On 11/19/2015 10:07 AM, Quentin Colombet via llvm-dev
wrote:
>> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
>>
>> On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at
apple.com> wrote:
>>> I must miss something, but I don’t get what is the problem of lower
the pointer to actual integer.
>> Pointers, in our architecture, are not integers.
> Thanks for the clarifications.
>
> So what you’re saying is that a inttoptr instruction is not a no-op on your
architecture, is that right?
> Or it can be a no-op only if the consumer of the pointer values can be done
on the pointer register bank?
>
> Don’t know if that helps, but note that the registers are not typed, they
just have size. The operations are typed.
>
> I am trying to understand the constraint to see how that would fit in the
framework. That being said, anything that you could do in SDag should be
possible as well in the new framework.
>
> Cheers,
> -Quentin
>
>> David
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 19 Nov 2015, at 19:27, Philip Reames <listmail at philipreames.com>
wrote:
> 
> Having a distinction between integers and pointers preserved into MI would
be quite useful for garbage collection as well.  We currently have a lowering
phase (RewriteStatepointsForGC) which effectively rewrites operations of
references (i.e. managed pointers) so that they can be treated as integers
throughout the rest of the pipeline.  If we could retain the distinction further
back through the backend, it would both simply a lot of code and likely let us
generate better code (spilling, etc..) around safepoints.
It’s also important for doing a load of CFI things correctly (see:
https://www.ics.uci.edu/~perl/ccs15_stackdefiler.pdf)

David

Hi David,

I had a quick look at the inttoptr/ptrtoint thing for GlobalISel and unless I am
mistaken the semantic you want for such instructions do not match what the
language reference says.

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 plan to stick to the LLVM IR semantic for the generic opcode of GlobalISel and
thus, it does not seem useful to have INTTOPTR like nodes around.

For instance, AArch64 has the TBI feature to deal more efficiently with fat
pointer when accessing memory and the masking operations are explicitly set in
the LLVM IR and later combine with the memory accesses.

Anyhow, this is just a heads-up, we will see in due time what we can do here.

Cheers,
-Quentin
> On Nov 19, 2015, at 10:53 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
> On 19 Nov 2015, at 18:07, Quentin Colombet <qcolombet at apple.com>
wrote:
>> 
>> 
>>> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
>>> 
>>> On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at
apple.com> wrote:
>>>> 
>>>> I must miss something, but I don’t get what is the problem of
lower the pointer to actual integer.
>>> 
>>> Pointers, in our architecture, are not integers.
>> 
>> Thanks for the clarifications.
>> 
>> So what you’re saying is that a inttoptr instruction is not a no-op on
your architecture, is that right?
> 
> Correct.
> 
>> Or it can be a no-op only if the consumer of the pointer values can be
done on the pointer register bank?
> 
> Yes (in some compilation models, we support 64-bit integers as pointers and
256-bit / 128-bit fat pointers, with the integer values being implicitly checked
against a large region identified by one of the fat pointer registers, giving a
coarse-grained sandbox that can communicate with the outside world via bounded
pointers).
> 
> We currently have entirely separate fat pointer and integer register banks,
though we’re investigating a mode where we’ll overlay the two on the same
register file (though they’ll likely treat some things as sub-registers.
> 
> It also means that address space casts are not a no-op for us, which I
believe is something that we share with some GPU ISAs (e.g. a 32-bit [or 16-bit]
local pointer cast to a 64-bit global address space is not a simple sign/zero
extension and so must be handled differently to an i32 -> i64 translation)
> 
>> Don’t know if that helps, but note that the registers are not typed,
they just have size. The operations are typed.
> 
> That’s fine, once you’ve assigned values to register banks.  The issue is
ensuring that we’re not throwing away the information that we need to do that
assignment in the translation from LLVM IR to the new machine IR (i.e. which
values are pointers, and which address space they are in).
> 
>> I am trying to understand the constraint to see how that would fit in
the framework. That being said, anything that you could do in SDag should be
possible as well in the new framework.
> 
> We currently add several new nodes to SDag: INTTOPTR, PTRTOINT, and PTRADD,
and a new iFATPTR MVT.  The last is somewhat problematic, as we really want to
have iFATPTR128 and iFATPTR256 (and, potentially, iFATPTR64 for an IoT/embedded
variant).
> 
> David
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/fbf1b688/attachment.html>