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

Hi David,

> On Nov 18, 2015, at 11:55 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
> Hi Quentin,
> 
> On 18 Nov 2015, at 19:26, Quentin Colombet via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> In the section “Goals", I defined (repeated for people that saw
the talk) the goals for the Global ISel design.
>> - Do you see anything missing?
>> - Do you see something that should not be there? 
> 
> I really like the design that you outlined.  I have one very small request:
> 
> Please maintain pointers as a distinct type from integers for as long as
possible.  We currently have some patches in SelectionDAG to add some
pointer-specific operations, as in our architecture the operations valid on
pointers are not the same as those valid on integers (and pointers are not the
same size as integers).  Your proposed model looks like it would be *much*
easier for us to use as long as that constraint is kept.  Various systems with
different integer and address registers hit the same problem as us.
I understand the problem, but I feel like Jakob back in the day:
http://lists.llvm.org/pipermail/llvm-dev/2013-August/064734.html
http://lists.llvm.org/pipermail/llvm-dev/2013-August/064760.html

To summarize with my own words and feelings that gives:
To me the pointer/integer distinction is a way for you to specify the register
classes you want. This is something the RegBankSelect pass will do for you and
this distinction should not be necessary to produce efficient or correct code.

If that doesn’t work, you should be able to have target specific pass to select
what you want directly after the translation or with a custom translation. One
can envision some kind of IRTranslationKit that has all the generic translation
build into to help you in such case.

Anyway, the good point with the prototype is that we will be able to experiment
these things :).
> 
> Given the way that you’re proposing to do legalisation, this seems like it
should be easy (for most architectures, assigning pointers to the same register
bank as integers will be a simple choice and then all of the later selection
should be the same).
> 
> On a related note, keeping pointer address spaces around in the machine IR
would make things easier for us and, I think, some of the GPU folks.
Good point, this is also something that the MachineInstr should also expose as
part of the make the IR self contained.

Thanks,
-Quentin
> 
> David
>

On 18 Nov 2015, at 23:52, Quentin Colombet <qcolombet at apple.com>
wrote:
> 
> To summarize with my own words and feelings that gives:
> To me the pointer/integer distinction is a way for you to specify the
register classes you want. This is something the RegBankSelect pass will do for
you and this distinction should not be necessary to produce efficient or correct
code.
> 
> If that doesn’t work, you should be able to have target specific pass to
select what you want directly after the translation or with a custom
translation. One can envision some kind of IRTranslationKit that has all the
generic translation build into to help you in such case.
> 
> Anyway, the good point with the prototype is that we will be able to
experiment these things :).
As long as the pointer vs integer distinction is preserved until the
RegBankSelect stage, then that will work for us.  The problem with the current
SelectionDAG ordering is that ‘what integer type do you use to represent
pointers?’ is the first question that the generic CodeGen infastructure asks the
back end during type legalisation, and the information is then gone (unless you
add new MVTs, as we’ve had to do).  If the initial lower preserves the
difference between pointer-in-address-space-X and i64, and we are allowed
register banks that overlap for final register allocation (which is almost
certainly needed for less exotic use cases anyway), then this scheme would be
*lot* easier for us to work with than the existing CodeGen infrastructure.

David

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
David Chisnall via llvm-dev
[..]
> 
> As long as the pointer vs integer distinction is preserved until the
RegBankSelect stage, then that will work for us.
> The problem with the...
[..]

+1

Greetings,

Jeroen Dobbelaere

Hi David,
> On Nov 19, 2015, at 1:57 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
> On 18 Nov 2015, at 23:52, Quentin Colombet <qcolombet at apple.com>
wrote:
>> 
>> To summarize with my own words and feelings that gives:
>> To me the pointer/integer distinction is a way for you to specify the
register classes you want. This is something the RegBankSelect pass will do for
you and this distinction should not be necessary to produce efficient or correct
code.
>> 
>> If that doesn’t work, you should be able to have target specific pass
to select what you want directly after the translation or with a custom
translation. One can envision some kind of IRTranslationKit that has all the
generic translation build into to help you in such case.
>> 
>> Anyway, the good point with the prototype is that we will be able to
experiment these things :).
> 
> As long as the pointer vs integer distinction is preserved until the
RegBankSelect stage, then that will work for us.  The problem with the current
SelectionDAG ordering is that ‘what integer type do you use to represent
pointers?’ is the first question that the generic CodeGen infastructure asks the
back end during type legalisation, and the information is then gone (unless you
add new MVTs, as we’ve had to do).  If the initial lower preserves the
difference between pointer-in-address-space-X and i64, and we are allowed
register banks that overlap for final register allocation (which is almost
certainly needed for less exotic use cases anyway), then this scheme would be
*lot* easier for us to work with than the existing CodeGen infrastructure.
I must miss something, but I don’t get what is the problem of lower the pointer
to actual integer.
As far as I can tell, what you want is to do some operation with some integers.
The fact that those are used as pointer or integer is orthogonal IMO.
What you really want is to make the best use of your instruction set, meaning
that if computing some pointer operations on the integer ISA is more efficient,
and vice-versa, this is what we want to do.

The address space information is only relevant when you actually access the
address, i.e., on memory operation, right?

What am I missing?

Cheers,
-Quentin
> 
> David
>