[Mesa-dev] [PATCH] glsl: Speed up constant folding for swizzles.

[Kenneth Graunke]

On Friday, September 12, 2014 04:30:55 PM Ian Romanick wrote:
> On 09/12/2014 03:16 PM, Kenneth Graunke wrote:
> > ir_rvalue::constant_expression_value() recursively walks down an IR
> > tree, attempting to reduce it to a single constant value.  This is
> > useful when you want to know whether a variable has a constant
> > expression value at all, and if so, what it is.
> > 
> > The constant folding optimization pass attempts to replace rvalues with
> > their constant expression value from the bottom up.  That way, we can
> > optimize subexpressions, and ideally stop as soon as we find a
> > non-constant subexpression.
> > 
> > In order to obtain the actual value of an expression, the optimization
> > pass calls constant_expression_value().  But it should only do so if it
> > knows the value can be combined into a constant.  Otherwise, at each
> > step of walking back up the tree, it will walk down the tree again, only
> > to discover what it already knew: it isn't constant.
> 
> Right... handle_rvalue happens for a node after all of its leaves have
> been processed, so swiz->val would already be ir_type_constant if it
> could be.  Since constant_expression_value is general, it tries to
> figure it out again.  Gotcha.
> 
> Are there other IR types that should get this treatment as well?
> 
> Either way, this patch is
> 
> Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>

Probably.  There are: expressions, textures, swizzles, dereferences, and constants.  Since textures are never constant expressions, the only ones we really need to handle are dereferences.

ir_dereference_variable probably doesn't need special treatment.

ir_dereference_array probably needs something.  It can be constant, if it's a constant array literal with constant indexing.  The array index could definitely be a giant non-constant expression tree we want to avoid walking.

I'm not sure what to do about the array itself, though.  It can be comprised of other dereferences, and swizzles...?  But not arbitrary expressions.  It's hard to imagine that growing to be a problem, but I guess it could.  Same goes for ir_dereference_record.

Thoughts?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140912/4c36b05e/attachment.sig>