<div dir="ltr"><div>> <span style="font-size:13px;font-family:arial,sans-serif">My only point is to keep hacks in the front-end until such a time when someone creates a PCS helper, rather than adding hacks all over the place. The former will make it easier to spot all the hacks until such day comes. This also seemed to be the general consensus for a number of years.</span><br>
</div>> <br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">>  But that's just a weak opinion, and I won't oppose to this change if other people feel it's the right way.</span><div class="gmail_extra">
<br></div><div class="gmail_extra">I contend that by "isolating" hacks in the frontend, they actually spill out through the publically visible interface of frontend -> midend. So while having hacks in both frontend and midend conceptually is worse for Clang+LLVM, I think this is only for the shorter term and the consequences of polluting the IR with another hack will live for much longer and is more difficult to clean up.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">James</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 March 2014 15:18, Oliver Stannard <span dir="ltr"><<a href="mailto:oliver.stannard@arm.com" target="_blank">oliver.stannard@arm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
  > I'm not advocating for piling up more hacks, because, even though this request implements the feature in the back-end (thus freeing the front-end from architectural decisions regarding HA on ARM), it will not free the front-end from architectural decisions regarding HA on other platforms, or anything else in them for that matter.<br>

<br>
</div>  Just because this doesn't fix all problems, I don't think that is a reason not do do it.<br>
<div class=""><br>
  > It'll also introduce code in the back-end to deal with an already existing hack (splitting structures into arguments), and once PCS helpers are in place, this code will be dead, as much as all other hacks in the front-end. Even though other front-ends can continue hacking the argument list as they are to deal with this PCS problem, new front-ends will still have to split them into arguments and maybe re-order them, which is still a hack.<br>

<br>
</div>  The code to split structs up into multiple arguments already exists in both clang //and// the backend, though I think the LLVM version will also split other types larger than one register, at least on some architectures. The whole point of this patch is that front-ends will no longer have to split struct arguments into multiple arguments (at least for ARM, I'm not familiar enough with other calling conventions to claim anything more general), and will not have to do any re-ordering.<br>

<div class=""><br>
  > My only point is to keep hacks in the front-end until such a time when someone creates a PCS helper, rather than adding hacks all over the place. The former will make it easier to spot all the hacks until such day comes. This also seemed to be the general consensus for a number of years.<br>

<br>
</div>  I understand your point about keeping the hacks together, assuming that there is a plan to remove them altogether, but surely it is better to fix the original problem (in this case, support for a limited set of types in the backend calling convention lowering) rather than pile on more hacks.<br>

<br>
  Has there been any discussion about changing/improving the way we handle calling conventions? I can't find anything in the mailing list archives, maybe it happened on IRC?<br>
<div class="HOEnZb"><div class="h5"><br>
<a href="http://llvm-reviews.chandlerc.com/D3082" target="_blank">http://llvm-reviews.chandlerc.com/D3082</a><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>