glsl ir csel inconsistency due to lower_if_to_cond_assign

I'm running into an assert on nv50 which is caused by lower_if_to_cond_assign.

After fixing a bug with an IR node being reused:

diff --git a/src/compiler/glsl/lower_if_to_cond_assign.cpp b/src/compiler/glsl/lower_if_to_cond_assign.cpp
index 8f1e800b888..8b969308f4a 100644
--- a/src/compiler/glsl/lower_if_to_cond_assign.cpp
+++ b/src/compiler/glsl/lower_if_to_cond_assign.cpp
@@ -204,7 +204,7 @@ move_block_to_cond_assign(void *mem_ctx,
                   new(mem_ctx) ir_expression(ir_triop_csel,
                                              cond_expr->clone(mem_ctx, NULL),
                                              assign->rhs,
-                                             assign->lhs->as_dereference());
+                                             assign->lhs->as_dereference()->clone(mem_ctx, NULL));
             }
          }
       }

I'm getting validation errors:

910           assert(ir->type == ir->operands[2]->type);
(gdb) l
905     
906        case ir_triop_csel:
907           assert(ir->operands[0]->type->is_boolean());
908           assert(ir->type->vector_elements == ir->operands[0]->type->vector_elements);
909           assert(ir->type == ir->operands[1]->type);
910           assert(ir->type == ir->operands[2]->type);
911           break;
(gdb) p ir->type
$1 = (const glsl_type *) 0x7ffff74e3380 <glsl_type::_float_type>
(gdb) p ir->operands[0]->type
$4 = (const glsl_type *) 0x7ffff74e2e40 <glsl_type::_bool_type>
(gdb) p ir->operands[1]->type
$5 = (const glsl_type *) 0x7ffff74e3380 <glsl_type::_float_type>
(gdb) p ir->operands[2]->type
$6 = (const glsl_type *) 0x7ffff74e3400 <glsl_type::_vec3_type>

So ... is this legal? MR !15540 (merged) added support for this construction incidentally, and the claim was that !14573 (merged) was the source of this in the first place.

So question is ... is this correct? Should such a csel be allowed? Seems awkward that the ir->type would be float, but would have a vec3 arg... Is assign_to_cv being used wrong in the pass?

This is easily hit with dEQP-GLES2.functional.shaders.algorithm.hsl_to_rgb_vertex on nv50, or anything else which sets the MaxIfDepth to 4 or less.

/cc @idr @anholt