[WaveTransform] Redesign lane mask contribution mechanism to propagate known subsets of exec

[lalaniket8]

Replace the analysis-driven, all-ones–materializing lane-mask merge with an explicit LaneMaskKind classification supplied by the caller during rewrite step. Callers now describe how each contribution relates to EXEC; buildMergeLaneMasks switches on that kind to pick the cheapest merge.

LaneMaskKind (new)

Enum classifying a lane mask vs. EXEC:

• Zero — Reg & EXEC == 0
• Subset — Reg & EXEC == Reg
• Exec — EXEC or -1 (Reg & EXEC == EXEC)
• NeedsMask — superset/unknown; emit Reg & EXEC

classifyLaneMask() derives it (EXEC → Exec, const ±1/0, subset via LMA, else NeedsMask).

buildMergeLaneMasks

• Takes LaneMaskKind CurKind instead of AMDGPULaneMaskAnalysis *LMA; branch selection is now a switch.
• Prev-zero + Zero emits MOV 0; accumulator + Zero elides the merge (copy only when Dst != Prev).

AMDGPULaneMaskUpdater

• addAvailable() gains a LaneMaskKind Kind argument.
• Dropped LMA member and setLaneMaskAnalysis().

AMDGPUWaveTransform

• Removed the RegAllOnes (-1) materialization and its dead-reg cleanup; EXEC/all-lanes contributions use LMC.ExecReg directly with LaneMaskKind::Exec.
• Each addAvailable() call passes an explicit kind (Exec/Zero/Subset).
• Added assert(!LaneOrigin.CondIsUndef).

AMDGPUWaitSGPRHazards (fix)

When sinking a wait before a terminator, anchor it before the first terminator (e.g. leading SI_WAVE_CF_EDGE) instead of before the branch, so it is not placed between terminator pseudos.

Effect

• No S_MOV_B64 -1 emitted for all-lanes contributions.
• Fewer redundant self-copies in accumulator merges.
• No functional change to computed EXEC values.

[rocm-cciapp]

PSDB Build Link: http://mlse-bdc-20dd129:8065/#/builders/10/builds/752

[cdevadas]

The changes look reasonable. But delay this patch until PR #3783 gets merged.

[cdevadas]

I posted PR #3813. Revert these changes later after it gets merged.

[rocm-cciapp]

PSDB Build Link: http://mlse-bdc-20dd129:8065/#/builders/10/builds/755

[rocm-cciapp]

PSDB Build Link: http://mlse-bdc-20dd129:8065/#/builders/10/builds/760

[cdevadas]

NeedsMask doesn't fit well as a Kind. It could be a None or Unknown for none-of-the-other known kinds. It should go as the first entry and push Zero down.

[lalaniket8]

NeedsMaks cannot be used as else because it represents 2 classes : Superset of exec and cases where no property is known about the register, in which case we conservatively chose to mask it.

[cdevadas]

Whether it's a superset or an unknown value, you eventually need a new Kind. NeedsMask doesn't accurately describe this category.
In situations like this, when it's difficult to come up with a concise and meaningful name, None or Unknown are commonly used. They represent the default state for values that don't naturally fit into any of the other defined MaskKinds.

[cdevadas]

Related question here;
Why do you have to add a single kind for both EXEC and AllOnes scenarios?
Don't we need a separate AllOnes kind just like Zero?

[lalaniket8]

That's a good question and relates to what earlier happened to the contributed AllOnes in the buildMergeLaneMasks section:
It has a bunch of ifs and elses that decide which lane mask instr is built - if it sees 'AllOnes' contributed, it replaces it with exec.

There is a single point in rewrite step2.1 where AllOnes is contributed. So we can safely contribute exec directly.

[cdevadas]

If AllOnes is replaced here, let's avoid mentioning -1 in the comment. There's no need to leave traces of intermediate designs as we are nearing the upstream effort.

[cdevadas]

I am trying to understand what scenario this -1 & EXEC == EXEC is?
Don't we have other combinations with -1?