<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="">Dave has the details sorted nicely, so I don’t have anything to add to that. To the question of adding a new TRI method for this, that seems a reasonable thing to me.<div class=""><br class=""></div><div class="">This is looking really interesting. Thanks!</div><div class=""><br class=""></div><div class="">-Jim</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Oct 8, 2014, at 11:32 AM, Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Dave,<div class=""><br class=""></div><div class="">Mostly cleaned up patch attached. There are still a few formatting changes, but almost exclusively in places where there are also functional changes.</div><div class=""><br class=""></div><div class="">Hope this helps.</div><div class=""><br class=""></div><div class="">- Lang.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Oct 8, 2014 at 10:08 AM, David Blaikie <span dir="ltr" class=""><<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Reformatting makes this patch a bit hard to follow - perhaps you could submit a separate reformat & then rebase the patch for easier review? (or at least when it's committed, so the revision history is a bit easier to follow)<br class=""><br class="">Yeah, I can't really make heads or tails of which bits of this have semantic changes.</div><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Tue, Oct 7, 2014 at 9:05 PM, Lang Hames <span dir="ltr" class=""><<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>></span> wrote:<br class=""></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="h5"><div dir="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">This patch removes the PBQPBuilder class and its subclasses and replaces them with a composable constraints class: PBQPRAConstraint. This allows constraints that are only required for optimisation (e.g. coalescing, soft pairing) to be mixed and matched. It also makes it easy for targets to supply custom constraints.</div><div class=""><br class=""></div><div class="">Most of this patch is PBQP-implementation nitty-gritty, but there's one part that I'd like some general feedback on: To enable targets to supply custom constraints I have added a new method to TargetRegisterInfo:</div><div class=""><br class=""></div><div class=""><font face="courier new, monospace" class="">virtual std::unique_ptr<PBQPRAConstraints> getCustomPBQPConstraints() const;</font></div><div class=""><br class=""></div><div class="">By default this returns a nullptr (indicating no custom constraints are to be used). TargetRegisterInfo seems like a reasonable place to have this, but if I've missed a more appropriate spot it would be good to know. (E.g. If we want to keep TargetRegisterInfo, as much as possible, as an interface for querying the target about the register file then perhaps it would make more sense to put this in TargetSubtargetInfo, but the policy in this area isn't clear to me).</div><div class=""><br class=""></div><div class="">On the assumption that TargetRegisterInfo is the right place for the aforementioned method, AArch64 has been updated to override this to supply its custom constraints. Arnaud - I'd appreciate it if you could take a quick look and let me know whether you're happy with these AArch64 changes.<br class=""></div><div class=""><br class=""></div><div class="">This patch should have no impact on allocation quality, and in almost all cases I would expect the resulting allocations to be identical. The only caveat is that PBQP uses FP, and this patch may slightly alter the order of FP operations during initialisation, which could alter some allocations. I would expect that to be very rare, if it happens at all.<br class=""></div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Lang.</div></div>
<br class=""></div></div>_______________________________________________<br class="">
llvm-commits mailing list<br class="">
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="">llvm-commits@cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</blockquote></div><br class=""></div>
<span id="cid:90508C75-D2CF-4F19-833D-92A3536E9D1A@apple.com"><pbqp-composable-constraints-2.patch></span>_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br class=""></div></blockquote></div><br class=""></div></body></html>