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

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
>

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.

David

> 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
>