[PATCH] Improve the way backends can provide their own PBQP constraints builder

[Arnaud A. de Grandmaison]

Lang, David,

 

Following up my PBQP patch for the AArch64, here is a patch improving how
targets can provide their own PBQP constraints builder.

 

I believe this patch is mostly sane, but could benefit from comments  in 2
areas:

1.       How can the backend know which regalloc is being used. In the
aarch64 case, using pbqp makes some passes useless. I solved that by
detecting that the default register allocator has been overridden from the
command line. That's not perfect, but it is simple & works, and I doubt many
people will be playing with 3 register allocators at the same time J

2.       Unique_ptr: I avoided coupling Target/TargetSubtargetInfo and
CodeGen/RegAllocPBQP by using a forward declaration of PBQPBuilder. This
prevents using a unique_ptr, which wants to see the destructor of the object
pointed to. This leads to a bit awkward code in
AArch64Subtarget::createPBQPConstraintsBuilder() where we have to get the
pointer out of the unique_ptr, to put it back in a unique_ptr in
createPBQPRegisterAllocator. Dave, would you have any suggestions there ?

 

Cheers,

--

Arnaud A. de Grandmaison

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140918/b0d69564/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PBQP-Improve-how-targets-provide-their-own-PBQP-cont.patch
Type: application/octet-stream
Size: 19701 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140918/b0d69564/attachment.obj>