[PATCH] [PBQP] Composable constraints.

[David Blaikie]

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)

Yeah, I can't really make heads or tails of which bits of this have
semantic changes.

On Tue, Oct 7, 2014 at 9:05 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi All,
>
> 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.
>
> 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:
>
> virtual std::unique_ptr<PBQPRAConstraints> getCustomPBQPConstraints()
> const;
>
> 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).
>
> 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.
>
> 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.
>
> Cheers,
> Lang.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141008/e4c79f95/attachment.html>