[Mesa-dev] [RFC] i965/fs: Generalize grf127 hack to dispatch_width > 8

[Caio Marcelo de Oliveira Filho]

Hi,

Thanks for the explanations :-)

> > -      ra_set_node_reg(g, grf127_send_hack_node, 127);
> > +      ra_set_node_reg(g, grf127_send_hack_node, 128 - reg_width);
> 
> This configuration is more restrictive than needed. The original code
> just avoids any register with any length that uses the physical register
> grf127. Your code works for SIMD16, but as you are setting conflicts
> with grf126 in SIMD16, you are forbidding the use of grf125 using with
> regsize=2, and the same with grf123 with size 4, when this options never
> use grf127. You don't need to take care of the reg_width here, just
> about which physical register you can not use.

That was my first attempt, but I think it was failing because of the
mistake below.



> >        foreach_block_and_inst(block, fs_inst, inst, cfg) {
> >           if (inst->is_send_from_grf() && inst->dst.file == VGRF) {
> >              ra_add_node_interference(g, inst->dst.nr, grf127_send_hack_node);
> > 
> 
> The issue here is that the unspill instructions aren't in the list of
> the is_send_from_grf. I thought we could update is_send_from_grf to
> include the read/write scratch operations but finally I think that it
> didn't have sense because  the source at this point is an MRF that will
> be finally assigned to a GRF on Gen7+.

Yes. Reading more of the spilling code today I can see how this won't
work. I was somehow under the idea that the actual register choice
would be preserved under a spill, but if we are spilling is precisely
because we don't have proper register allocation.

 
> I've sent a patch with my solution that I think solves the case of
> unspill that is creating this problem, but maybe we need to think if
> there are more SEND instructions that could have this problem because of
> using the MRF as source.

Great! I'll take a look.


Thanks,
Caio