Hi Jakob, On Thu, Oct 4, 2012 at 1:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Oct 4, 2012, at 2:47 AM, Madhusudan C.S <madhusudancs at gmail.com> wrote: > > However, I was reading the DeveloperPolicy page and the policy for making > major > changes asks the developers to discuss the work here before proceeding. > So, I am > writing this mail to kickoff a discussion. I would really like to > contribute to LLVM and > I think this is a good place for me to start. Is there something specific > like a paper > that you guys would want me to read before diving in? > > I understand that register allocation itself is a tricky problem and doing > an interprocedural > allocation is extremely hard. But I would like to try, at least try and > fail if worst comes > to worst than not doing anything at all. At least by attempting to > implement that, I will > have a better understanding of LLVM code base which may come in handy to > contribute > to other parts of LLVM. > > > Interprocedural register allocation means different things to different > people. The approach that is described on the open projects page is quite > simple; it still runs the register allocator on one function at a time. > > I am not aware of any papers describing this simple idea. > > Basically, the PrologEpilogInsertion pass will add a bit mask to > MachineModuleInfo describing which registers are clobbered by the function > being compiled. Later, when compiling the callers, that bit mask is used to > initialize the regmask operands on call instructions. >So the idea is to sidestep from the calling convention a bit if we already know that the called function will not be using all the registers required by the convention and instead use those registers in the caller? If I am understanding this correctly, is this something desirable for LLVM, even if it is not high priority? Would you guys be Ok if I try to implement this without disturbing the project priorities but with a little help/guidance? Something that interests me to get started with LLVM.> > See also TargetRegisterInfo::getCallPreservedMask(). > > /jakob > >-- Thanks and regards, Madhusudan.C.S -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121004/a5de8fff/attachment.html>
On Oct 4, 2012, at 2:27 PM, "Madhusudan C.S" <madhusudancs at gmail.com> wrote:> Basically, the PrologEpilogInsertion pass will add a bit mask to MachineModuleInfo describing which registers are clobbered by the function being compiled. Later, when compiling the callers, that bit mask is used to initialize the regmask operands on call instructions. > > So the idea is to sidestep from the calling convention a bit if we > already know that the called function will not be using all the > registers required by the convention and instead use those registers > in the caller?That's right.> If I am understanding this correctly, is this something desirable for > LLVM, even if it is not high priority?Yes.> Would you guys be Ok if I try > to implement this without disturbing the project priorities but with > a little help/guidance?Absolutely. /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121004/592358fa/attachment.html>
Hi Jakob, On Thu, Oct 4, 2012 at 2:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Oct 4, 2012, at 2:27 PM, "Madhusudan C.S" <madhusudancs at gmail.com> > wrote: > > Basically, the PrologEpilogInsertion pass will add a bit mask to >> MachineModuleInfo describing which registers are clobbered by the function >> being compiled. Later, when compiling the callers, that bit mask is used to >> initialize the regmask operands on call instructions. >> > > So the idea is to sidestep from the calling convention a bit if we > already know that the called function will not be using all the > registers required by the convention and instead use those registers > in the caller? > > > That's right. > > If I am understanding this correctly, is this something desirable for > LLVM, even if it is not high priority? > > > Yes. > > Would you guys be Ok if I try > to implement this without disturbing the project priorities but with > a little help/guidance? > > > Absolutely. >Great! Thank you very much. Then, I will do some homework on how I plan to implement this, a _very_ rough sketch if not the actual design, and come back. Btw, I just found this http://optimisticcompilers.blogspot.com/ So I will just take a look at what happened to that project.> > /jakob > >-- Thanks and regards, Madhusudan.C.S -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121004/14ee9dd8/attachment.html>