On Fri, Oct 5, 2012 at 2:41 PM, William J. Schmidt <span dir="ltr"><<a href="mailto:wschmidt@linux.vnet.ibm.com" target="_blank" class="cremed">wschmidt@linux.vnet.ibm.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, 2012-10-05 at 14:29 -0700, Chandler Carruth wrote:<br>
> On Fri, Oct 5, 2012 at 2:25 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="cremed">hfinkel@anl.gov</a>> wrote:<br>
><br>
><br>
>         ----- Original Message -----<br>
>         > From: "William J. Schmidt" <<a href="mailto:wschmidt@linux.vnet.ibm.com" class="cremed">wschmidt@linux.vnet.ibm.com</a>><br>
>         > To: <a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
>         > Sent: Friday, October 5, 2012 4:20:53 PM<br>
>         > Subject: [llvm-commits] [PATCH, PowerPC] Split Darwin and<br>
>         64-bit SVR4 processing of LowerFormalArguments<br>
>         ><br>
>         > The attached patch is some TLC to split apart a function<br>
>         being used<br>
>         > by<br>
>         > both Darwin and 64-bit SVR4 ABIs.  There is no change in<br>
>         function.  I<br>
>         > have plans to make some nontrivial changes to the SVR4 ABI<br>
>         handling,<br>
>         > and<br>
>         > having the two ABIs separated will be better for all<br>
>         concerned.<br>
>         ><br>
>         > Tested with no new regressions.  Ok to commit?<br>
><br>
><br>
>         Alright (I assume the large block is copied from the Darwin<br>
>         version), LGTM.<br>
><br>
><br>
> Maybe I'm just confused, but why is it OK to copy/paste so much code<br>
> from Darwin? IS the code going away as you refactor it, or is there<br>
> actually a need to build an abstraction shared between the two?<br>
><br>
><br>
> (I may just not understand the end goal of the patch, in which case a<br>
> better explanation will fix matters...)<br>
><br>
<br>
</div></div>I do have plans to refactor some of the code.  The fact is that the SVR4<br>
ABI has requirements that Darwin doesn't have, and littering the code<br>
with "this part is for Darwin, this part is for SVR4" is going to get<br>
unworkable pretty fast.<br>
<br>
An example of what's missing:  64-bit SVR4 requires that a callee that<br>
takes the address of any parameter must copy any parameters passed in<br>
registers into the caller's stack frame at certain reserved locations.<br>
Because of how the code is structured, that's going to require some<br>
rip-up of the ordering of events.  Rather than worrying all the time<br>
about breaking the Darwin ABI, I want to separate the two now before<br>
things become too messy.<br>
<br>
There are several other deficiencies in parameter passing for which I've<br>
opened a number of bug reports, many of which need to be solved in this<br>
same code.<br>
<br>
This patch is just to tease the two apart in the most straightforward<br>
way possible.  Factoring will be done as part of the upcoming work.<br>
<br>
Hope this helps!<br></blockquote><div><br></div><div>Yes, very much. Thanks for the explanation. =]</div></div></div>