Skip to content

intel/brw: Always have a (non-DO) block after a DO in the CFG

Caio Oliveira requested to merge cmarcelo/mesa:push-oztkqoqtorop into main

Make the "block after DO" more stable so that adding instructions after a DO doesn't require repairing the CFG. Use a new SHADER_OPCODE_FLOW instruction that is a placeholder representing "go to the next block" and disappears at code generation.

For some context, there are a few facts about how CFG currently works

  • Blocks are assumed to not be empty;
  • DO is always by itself in a block, i.e. starts and ends a block;
  • There are no empty blocks;
  • Predicated WHILE and CONTINUE will link to the "block after DO";
  • When nesting loops, it is possible that the "block after DO" is another "DO".

Reasons and further explanations for those are in the brw_cfg.c comments.

What makes this new change useful is that a pass might want to add instructions between two DO instructions. When that happens, a new block must be created and any predicated WHILE and CONTINUE must be repaired.

So, instead of requiring a repair (which has proven to be tricky in the past), this change adds a block that can be "virtually" empty but allow instructions to be added without further changes.

One alternative design would be allowing empty blocks, that would be a deeper change since the blocks are currently assumed to be not empty in various places. We'll save that for when other changes are made to the CFG.

The problem described happens in brw_opt_combine_constants, and a there's a patch in the MR to clean that up.

Merge request reports