[PATCH] [PBQP] Composable constraints.

[Lang Hames]

Hi Dave,

Mostly cleaned up patch attached. There are still a few formatting changes,
but almost exclusively in places where there are also functional changes.

Hope this helps.

- Lang.


On Wed, Oct 8, 2014 at 10:08 AM, David Blaikie <dblaikie at gmail.com> wrote:

> 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/981d5bb3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pbqp-composable-constraints-2.patch
Type: application/octet-stream
Size: 66886 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141008/981d5bb3/attachment.obj>