[Mesa-dev] [PATCH 00/13] i965 vs: Split vec4_visitor into two classes.

[Paul Berry]

In order to implement transform feedback on Gen6, we need to create a
geometry shader program that will stream out the transformed vertices.
It makes sense to re-use parts of the vec4_visitor infrastructure to
do this, because (a) VS and GS handle data very similarly, (b) it
allows us to take advantage of the optimization and register
allocation code in vec4_visitor, and (c) in the long run when we add
support for GLSL geometry shaders, we are going to need to use the
vec4_visitor infrastructure to compile them.

This patch series gets us ready for re-using parts of vec4_visitor, by
breaking it into a base class containing the parts we are likely to
re-use, and a derived class containing the parts we aren't.  The base
class, vec4_generator, is responsible for code generation, register
allocation, and optimization; it is independent of GLSL IR (with one
trivial exception), and mostly independent of the type of shader being
compiled.  The derived class, vec4_visitor, is responsible for
visiting the GLSL IR and performing vertex-shader-specific actions.

This split was already implicitly present in the code; this patch
series merely makes it more explicit.

The idea is that for now, we can make a class that derives from
vec4_generator to do transform feedback, and we won't have to worry
too much about interactions with the GLSL IR visiting code in
vec4_visitor.  Later, when we add support for GLSL geometry shaders,
we'll have to do further work on vec4_visitor, but we won't have to
touch vec4_generator very much.

Patches 01-11 are all preparatory refactoring: they make small
adjustments to the functioning of vec4_visitor so that the separation
between its IR visiting parts and its code generation parts is a
little more strict.  Patch 12 splits the classes up, and then patch 13
reformats the class declarations to clarify the relationship between
the two classes.

The split isn't perfect yet; there are a few places where
vec4_generator still makes implicit assumptions that are vertex-shader
specific (particularly in register allocation), and there are a few
places where vec4_visitor still does things that arguably should be
part of code generation (such as setting up scratch registers).  But I
think this is close enough that we can clean those up with later
patches on an as-needed basis.

Note: To ease reading the diffs, I didn't make any effort to move code
between .cpp files.  As a result, vec4_visitor and vec4_generator code
are intermingled in brw_vec4_visitor.cpp, brw_vec4_emit.cpp,
brw_vec4.cpp, brw_vec4_copy_propagation.cpp, and
brw_vec4_reg_allocate.cpp.  Once this patch is reviewed and we've
settled on how we want the classes to be split up, I'll make a
follow-up patch that rearranges the .cpp files to match the changes to
the class structure.

[PATCH 01/13] i965 vs: Remove dead code from the vec4_visitor class.
[PATCH 02/13] i965 vs: Make reg_allocate() return total_grf.
[PATCH 03/13] i965 vs: Return last_scratch from move_grf_array_access_to_scratch()
[PATCH 04/13] i965 vs: Make first_non_payload_grf an explicit function arguments.
[PATCH 05/13] i965 vs: Move brw_set_access_mode() call into generate_code().
[PATCH 06/13] i965 vs: Move the call to reg_allocate() inside of generate_code().
[PATCH 07/13] i965 vs: Streamline the way fail is tracked.
[PATCH 08/13] i965 vs: Add get_debug_flag()
[PATCH 09/13] i965 vs: Add get_debug_name().
[PATCH 10/13] i965 vs: Make a separate optimize() method.
[PATCH 11/13] i965 vs: Make get_assignment_lhs() a method
[PATCH 12/13] i965 vs: Separate IR visiting from code generation in vec4_visitor;
[PATCH 13/13] i965 vs: Rearrange class declarations.