Quentin Colombet via llvm-dev
2015-Nov-19 17:49 UTC
[llvm-dev] [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 >
David Chisnall via llvm-dev
2015-Nov-19 17:50 UTC
[llvm-dev] [GlobalISel] A Proposal for global instruction selection
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
Quentin Colombet via llvm-dev
2015-Nov-19 18:07 UTC
[llvm-dev] [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 >
Reasonably Related Threads
- [GlobalISel] A Proposal for global instruction selection
- [GlobalISel] A Proposal for global instruction selection
- [GlobalISel] A Proposal for global instruction selection
- [LLVMdev] Legalizing SelectionDAGs with illegal pointer type
- [GlobalISel][RFC] Value to vreg during IR to MachineInstr translation for aggregate type