[PATCH 3/3] [PBQP] Enforce a safe order for ConservativelyAllocatableNodes

Arnaud A. de Grandmaison arnaud.degrandmaison at arm.com
Tue Nov 4 12:31:57 PST 2014


I am not sure I will have time in the next few days, but I am interested in rewriting the patch and learn to use your new metadata infrastructure.

 

Using a priority queue was what I wanted to do at first J

 

Cheers,

Arnaud

 

From: Lang Hames [mailto:lhames at gmail.com] 
Sent: 04 November 2014 19:56
To: Arnaud De Grandmaison
Cc: Commit Messages and Patches for LLVM
Subject: Re: [PATCH 3/3] [PBQP] Enforce a safe order for ConservativelyAllocatableNodes

 

Hello Arnaud,

 

This is a good idea, but the implementation in this patch will make removal of conservatively allocatable nodes more expensive: from O(N) to O(RN^2), where R is the number of registers and N is the number of nodes. We can get that back down to O(RN + NlogN) by creating a VectorMetadata class that contains the expected/worst-case cost, and using a set (or better yet, a priority_queue) to hold the conservatively allocatable nodes. This is the same line of reasoning that was applied (very successfully) to MatrixMetadata to bring down the cost for the conservative-allocatability test itself.

 

If you're happy to rewrite your patch along those lines please go for it, otherwise I can find some time to do it in the next few days. It is not a big change at all, though it helps that I'm familiar with the infrastructure.

 

Cheers,

Lang.

 

 

On Wed, Oct 22, 2014 at 6:43 AM, Arnaud A. de Grandmaison <arnaud.degrandmaison at arm.com> wrote:

Hi Lang,

 

Here is the last patch in the PBQP improvement serie. Could you please have a look at it ?

 

Nodes in ConservativelyAllocatableNodes were processed in the order they

have been added in NodeSet; however, it is preferable to process nodes in

an order based on their cost, to ensure we keep the total cost under

control and provide a reasonable solution.

 

Cheers,

--

Arnaud A. de Grandmaison

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141104/96b78dc6/attachment.html>


More information about the llvm-commits mailing list