[Mesa-dev] Case where opt_copy_propagation doesn't do its job

[Bryan Cain]

On 07/12/2011 04:36 PM, Eric Anholt wrote:
> On Tue, 12 Jul 2011 15:44:12 -0500, Bryan Cain <bryancain3 at gmail.com> wrote:
>> It appears that the copy propagation pass in the GLSL compiler (in
>> opt_copy_propagation.cpp) doesn't do copy propagation when the
>> components of a variable are initialized separately, like this:
>>
>> (declare (temporary ) vec4 vec_ctor)
>> (assign  (w) (var_ref vec_ctor)  (constant float (1.000000)) )
>> (assign  (xyz) (var_ref vec_ctor)  (var_ref assignment_tmp at 16) )
>> (assign  (xyzw) (var_ref gl_FragColor)  (var_ref vec_ctor) )
>>
>> In the past, this wasn't visible in the Mesa IR output because Mesa IR
>> optimization seems to do the copy propagation.  However, glsl_to_tgsi
>> doesn't do copy propagation to output registers - in fact, I believe
>> this is the only case left where ir_to_mesa produces better code than
>> glsl_to_tgsi.  I'm not very enthusiastic about the idea adding to the
>> copy propagation pass in glsl_to_tgsi, since this case is something that
>> should really be optimized by the GLSL compiler before it reaches the IR
>> backend.
>>
>> So, is there a reason why the GLSL copy propagation pass doesn't operate
>> per-component?
> opt_copy_propagation_elements does that, but it doesn't split up the
> assignment into multiple assignments (otherwise, imagine initializing
> vec_ctor once and using it many times -- how do you decide whether copy
> propagate or not, to avoid pessimizing the code?).
>
> I think the operation you're looking for isn't really copy propagation,
> but more like register coalescing where you see that vec_ctor doesn't
> get redefined and used after being assigned to gl_FragColor, and just
> store the two in the same place.  And yes, I think it would be useful to
> have something like that.

Oops, I don't have a very good vocabulary of compiler terms, and after
looking at the file I started to realize it wasn't copy propagation I
was looking for.  But you're right, that's a good idea, and maybe I can
try writing a pass for that.  If I'm thinking about this right, it would
just track which variables are only dereferenced once, and where that
dereference is in an assignment; then it would change the LHS of the
assignment(s) to the first variable and replace it with the new one.

Actually, if that were done for all variables, it would involve tracking
whether the second variable is used in between assignment and
dereference of the first variable.  So I think I'll just do it for
ir_var_out variables instead.  They're the only ones that are causing me
a problem, anyway.

> Either that or generate new ir_quadop_vector in copy propagation.

I don't understand how that solution would work.