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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev