llvm dev - Oct 2017 - Status of PBQP register allocator?

Hi all,

I was wondering about whether the PBQP register allocator is likely to be
maintained in the future.  It's proving to be a nice way to encode some
instruction encoding constraints for an out-of-tree backend we have, but
there's concern about it being abandoned or bitrotting in the future.

Also, if PBQP is likely to lapse out of regular maintenance in the future,
is there a simple way to express constraints on allocated registers (such
as sharing an encoding, despite being in different register classes) chosen
for a particular instruction in the Greedy allocator?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/85595ef9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4837 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/85595ef9/attachment.bin>

+Lang

Hi Nate,
> On Oct 5, 2017, at 2:41 PM, Nate Voorhies via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> I was wondering about whether the PBQP register allocator is likely to be
maintained in the future.  It's proving to be a nice way to encode some
instruction encoding constraints for an out-of-tree backend we have, but
there's concern about it being abandoned or bitrotting in the future.
The PBQP allocator is not going away and in particular Lang actively maintains
it when need be.
> 
> Also, if PBQP is likely to lapse out of regular maintenance in the future,
is there a simple way to express constraints on allocated registers (such as
sharing an encoding, despite being in different register classes) chosen for a
particular instruction in the Greedy allocator?
You can use the hint mechanism to express your encoding constraints based on
what is already allocated. See TargetRegisterInfo::getRegAllocationHints.

Cheers,
-Quentin
> 
> Thanks!
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Nate,

PBQP hasn't received a lot of attention recently, but that's due to the
odd
combination of (a) it being fairly robust and isolated (and so not much of
a maintenance burden) and (b) it having few users.

I think you should feel free to use it -- I don't think it's going away
any
time soon. Plus, the more users it has the more interested people may be in
improving it further.

If you do encounter any bugs in it please file a bug on bugs.llvm.org and
CC me. In my experience the algorithm is simple enough that fixes are
usually fairly straightforward.

Cheers,
Lang.

On Thu, Oct 5, 2017 at 9:19 PM, Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +Lang
>
> Hi Nate,
>
> > On Oct 5, 2017, at 2:41 PM, Nate Voorhies via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > I was wondering about whether the PBQP register allocator is likely to
> be maintained in the future.  It's proving to be a nice way to encode
some
> instruction encoding constraints for an out-of-tree backend we have, but
> there's concern about it being abandoned or bitrotting in the future.
>
> The PBQP allocator is not going away and in particular Lang actively
> maintains it when need be.
>
> >
> > Also, if PBQP is likely to lapse out of regular maintenance in the
> future, is there a simple way to express constraints on allocated registers
> (such as sharing an encoding, despite being in different register classes)
> chosen for a particular instruction in the Greedy allocator?
>
> You can use the hint mechanism to express your encoding constraints based
> on what is already allocated. See TargetRegisterInfo::
> getRegAllocationHints.
>
> Cheers,
> -Quentin
>
> >
> > Thanks!
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/62394dde/attachment.html>