[Mesa-dev] [PATCH] ra: Add ra_set_node_reg()

[Tom Stellard]

On Sun, Apr 24, 2011 at 02:00:40PM -0700, Eric Anholt wrote:
> On Tue, 19 Apr 2011 23:09:46 -0700, Tom Stellard <tstellar at gmail.com> wrote:
> > This function makes it possible to include input / payload registers in
> > the interference graph.
> 
> [...]
> 
> > +/**
> > + * This function allows a user to manually assign a register to a node.  This
> > + * is useful for nodes that belong to register classes that contain a very small
> > + * number of registers that are not likely to be allocated if they end up at
> > + * the bottom of the stack.
> > + */
> > +void
> > +ra_set_node_reg(struct ra_graph *g, unsigned int n, unsigned int reg)
> > +{
> > +   g->nodes[n].reg = reg;
> > +   g->nodes[n].in_stack = GL_FALSE;
> > +}
> > +
> 
> So, this problem could also be solved by creating a register class per
> payload register and including the nodes for the payload data in those
> classes, right?  However, I think you've got a good, safe solution for
> some common uses that doesn't cause the size of the allocator data to
> explode even more.
> 

In order to include the payload registers in the interference graph,
it is necessary to create classes for them *and* use ra_set_node_reg().
Simply creating classes for the payload registers won't work, because
if the payload nodes aren't the first nodes popped off the stack, then
the payload registers will be assigned to non-payload nodes before they
can be assigned to the payload nodes.  However, the payload nodes still
need to be assigned to a class, otherwise the allocator will crash during
the pq test.

> The comment I think I would have written for this function is:
> 
> /**
>  * Forces a node to a specific register.  This can be used to avoid
>  * creating a register class containing one node when handling data
>  * that must live in a fixed location and is known to not conflict
>  * with other forced register assignment (as is common with shader
>  * input data).  These nodes do not end up in the stack during
>  * ra_simplify(), and thus at ra_select() time it is as if they were
>  * the first popped off the stack and assigned their fixed locations.
>  *
>  * Must be called before ra_simplify().
>  */

I'll fix up the comment to better explain what is happening.
> 
> Overall,
> 
> Reviewed-by: Eric Anholt <eric at anholt.net>