<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><div></div><div><br class=""></div><div>I'd imagine the second part could be implemented with an analysis that would be queried to get a possible regmask on each call.</div><div><br class=""></div><div>-- </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Allocate remaining functions “normally”.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think the main challenge of a real inter-procedural register allocator is to change all of the calling convention dynamically and more importantly convey the right information to other tools (via CFA, CFI, etc.).<br class="">
<br class=""></blockquote><div class="">Here for calling convention do you mean that has to be handle for different kind of backends differently or you are referring some thing I don't know. I don't understand what do you mean by 'convey the right information to other tool' if we have updated regmask for a call instruction then MachineFunction should be able to reflect that fact in MachineFunction pass which is used for intra-procedural register allocation, all we have done is allocated some registers that should live across the function call.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">My mistake, I though you had in mind what I call a “true” inter procedural registers allocator: one that changes the allocation at function boundaries as well. I.e., it may choose that it is more efficient to put the first argument of function foo is register FP0 even if the ABI says R0.</div><div class="">With this kind of scheme, you break the ABI (and you need LTO to be allowed to do that), you need to “dynamically” adjust the calling convention to what the register allocator chooses, and moreover you need to be able to communicate to the other tools (dynamic linker, debugger, etc.) where are the things that are usually defined by the ABI, like the frame pointer, the return value, etc.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">Vivek</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Cheers,<br class="">
Q.<br class="">
<div class=""><div class="h5">> On Mar 22, 2016, at 6:04 PM, Matthias Braun <<a href="mailto:mbraun@apple.com" class="">mbraun@apple.com</a>> wrote:<br class="">
><br class="">
> No need to apologize this thread surely deserved some answers :)<br class="">
><br class="">
> From my perspective this project sounds doable. I would expect the register allocation parts to be not too hard: I imagine this being just distilling a new clobber regmask after allocating a function. I would expect the challenging (or annoying) part to get a machine module pass (or a similar mechanism to influence the order in which functions are processed) and a callgraph in the backend. So this might end up being more pass manager / infrastructure work than register allocation.<br class="">
><br class="">
> I'd be happy to answer detail questions or give guidance on the register allocation aspects.<br class="">
><br class="">
> - Matthias<br class="">
><br class="">
>> On Mar 22, 2016, at 5:27 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" class="">sanjoy@playingwithpointers.com</a>> wrote:<br class="">
>><br class="">
>> Apologies: didn't notice how old this thread is before replying.<br class="">
>><br class="">
>> On Tue, Mar 22, 2016 at 5:24 PM, Sanjoy Das<br class="">
>> <<a href="mailto:sanjoy@playingwithpointers.com" class="">sanjoy@playingwithpointers.com</a>> wrote:<br class="">
>>> Hi Vivek,<br class="">
>>><br class="">
>>> [+CC Matthias, Quentin]<br class="">
>>><br class="">
>>> Inter-procedural register allocation can be a big win, but my estimate<br class="">
>>> is that it will be challenging to complete within one summer unless<br class="">
>>> you're already familiar with LLVM's register allocator.<br class="">
>>><br class="">
>>> I've CC'ed some people who can give you some more detailed information.<br class="">
>>><br class="">
>>> -- Sanjoy<br class="">
>>><br class="">
>>><br class="">
>>> On Tue, Feb 9, 2016 at 9:17 PM, vivek pandya via llvm-dev<br class="">
>>> <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
>>>> Hello Community,<br class="">
>>>><br class="">
>>>> I would like to know status of the project and also importance of it. If the<br class="">
>>>> project is still open I would like to work on GSoC 2016 proposal for<br class="">
>>>> Inter-procedural Register Allocation, in that case please also suggest<br class="">
>>>> possible mentor or let me know if anyone is willing to be mentor for this.<br class="">
>>>><br class="">
>>>> Sincerely,<br class="">
>>>> Vivek Pandya<br class="">
>>>><br class="">
>>>><br class="">
>>>> _______________________________________________<br class="">
>>>> LLVM Developers mailing list<br class="">
>>>> <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
>>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
>>>><br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>> --<br class="">
>>> Sanjoy Das<br class="">
>>> <a href="http://playingwithpointers.com/" rel="noreferrer" target="_blank" class="">http://playingwithpointers.com</a><br class="">
>><br class="">
>><br class="">
>><br class="">
>> --<br class="">
>> Sanjoy Das<br class="">
>> <a href="http://playingwithpointers.com/" rel="noreferrer" target="_blank" class="">http://playingwithpointers.com</a><br class="">
><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>