Thanks Eli, Jaffrey for the pointer! A couple of further questions if I may 1. Isnt this assuming that register being pinned to is always esi when it comes to using a calling convention. I would like to pin the register through a pass and so I dont know which registers ends up being used for a particular value before hand 2. I would also like to allocate some small aggregates into registers. I understand that the code generation would need to be non trivially modified to do this. I am wondering if it would be possible to create a map of this information and using it in a modified existing allocator. Modification would make sure the already allocated registers are not available. thanks again shrey On Thu, Jul 16, 2009 at 2:05 PM, Jeffrey Yasskin<jyasskin at google.com> wrote:> Chris recently wrote up a way to do this at > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > On Thu, Jul 16, 2009 at 1:53 PM, shreyas krishnan<shreyas76 at gmail.com> wrote: >> Hi >> As part of a requirement that I have, I would like to have some >> globals reside in registers always. So these variables would not have >> a home location in memory. >> I realize the code generated would also need to be aware of this. I do >> have some ideas on how to change the code appropriately. But right >> now, I am more concerned about how to fit this requirement (sort of >> interprocedural) into the existing LLVM register allocation framework. >> While I can as part of pre regalloc pass allocate globals to >> registers, how can I share this information between allocation of >> different functions. >> >> Allocation efficiency is not as much a concern and I am ok with doing >> the allocation as a pre ra pass. >> I will appreciate any pointers ! >> Shrey >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Thu, Jul 16, 2009 at 2:41 PM, shreyas krishnan<shreyas76 at gmail.com> wrote:> Thanks Eli, Jaffrey for the pointer! > > A couple of further questions if I may > 1. Isnt this assuming that register being pinned to is always esi when > it comes to using a calling convention.You'd need a separate calling convention for each possible set of registers pinned. The combinatoric possibilities can get ugly, but you probably only need a small fraction of the possibilities.> 2. I would also like to allocate some small aggregates into registers. > I understand that the code generation would need to be non trivially > modified to do this.You can always just split them in your pass... I don't know off the top of my head whether returning a nested structure works at the moment.> I am wondering if it would be possible to create a map of this > information and using it in a modified existing allocator. > Modification would make sure the already allocated registers are not > available.You could, but it would be an ugly hack. -Eli
Thanks Eli. At a implementation level, I am wondering if there is any target specific class that I can use to store this information and use it in the modified allocator later. thanks shrey On Thu, Jul 16, 2009 at 3:12 PM, Eli Friedman<eli.friedman at gmail.com> wrote:> On Thu, Jul 16, 2009 at 2:41 PM, shreyas krishnan<shreyas76 at gmail.com> wrote: >> Thanks Eli, Jaffrey for the pointer! >> >> A couple of further questions if I may >> 1. Isnt this assuming that register being pinned to is always esi when >> it comes to using a calling convention. > > You'd need a separate calling convention for each possible set of > registers pinned. The combinatoric possibilities can get ugly, but > you probably only need a small fraction of the possibilities. > >> 2. I would also like to allocate some small aggregates into registers. >> I understand that the code generation would need to be non trivially >> modified to do this. > > You can always just split them in your pass... I don't know off the > top of my head whether returning a nested structure works at the > moment. > >> I am wondering if it would be possible to create a map of this >> information and using it in a modified existing allocator. >> Modification would make sure the already allocated registers are not >> available. > > You could, but it would be an ugly hack. > > -Eli > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >