[AMDGPU] TTI: Prioritize per-iter base adds in LSR plan comparison

[michaelselehov]

AMDGPU: reflect lack of complex addressing in LSR; fix regressions after SROA copy-load promotion

Background

Recent SROA changes promote copy-load style IR more aggressively. As a side effect, LoopStrengthReduce (LSR) now triggers on loops where it previously stayed quiet. On AMDGPU (no rich base+index addressing modes), generic LSR heuristics could pick plans that looked cheaper but expanded into extra address formation work in the loop body, causing performance regressions.

Problem

• A scaled index with a base register is not free on AMDGPU; it becomes an extra per-iteration add.
• LSR’s Insns metric did not count this address work, so plans could “win” by 1 instruction in theory but actually add a v_add in the loop.
• On GFX9+ we care more about per-iteration work than about small, one-time preheader setup.

Solution

• Implement getScalingFactorCost in GCNTTIImpl to model scaled addressing:
  If HasBaseReg && Scale != 0, return cost 1 (one extra per-iteration instruction).
• Use Effective Insns as the top metric in isLSRCostLess (GFX9+):
  Effective Insns = Insns + ScaleCost
  This makes scaled address formation count as real per-iteration work.

Priority order on GFX9+

1. Effective Insns (Insns + ScaleCost)
2. NumIVMuls (penalize mul/mul_hi/addc IV chains)
3. AddRecCost (prefer fewer IV updates)
4. NumBaseAdds
5. SetupCost
6. ImmCost
7. NumRegs

• Pre-GFX9 behavior is unchanged (fall back to base implementation).

Rationale

• AMDGPU lacks hardware complex addressing. Base + (iv * scale) requires an extra instruction; modeling that as ScaleCost = 1 and folding into Effective Insns fixes false “wins”.
• Keeping NumIVMuls high in the order preserves the important penalty for wide IV mul chains (problematic on gfx942).
• Preheader work remains a lower priority; we accept modest setup if per-iteration work is not worse (often better).

Validation

• Micro cases that previously regressed now choose pointer IV or a single IV with honest accounting of address work; per-iteration VALU pressure is reduced or unchanged.
• A GlobalISel case that relies on fewer IV updates still selects the intended plan (no scale involved, so Effective Insns ties and AddRecCost wins).
• AMDGPU lit tests with autogenerated checks were reviewed and selectively regenerated where code shape improved or shifted benignly. Intent-based tests (no crashes, correct sinking, correct divergence handling) remain valid.
• Bench on gfx942 remains stable; no increase in actual loop work.

Notes

• No LSR algorithms were changed; this is TTI cost modeling and plan ordering for AMDGPU.
• Scope is limited to GFX9+.
• Further tuning can be added later if we find unrolled-shape outliers, but current data shows this approach addresses the original regressions without harming other cases.

P.S. The commented-out debug messages will stay there till the final form (waiting for CQE extensive perf testing), then I'll remove them.

To fix the problem, explicitly declare a permissions: block at the root of the workflow YAML file (line 2, immediately after the name: and before on:) to limit the GITHUB_TOKEN supplied to jobs. As a minimal baseline, set contents: read, which allows only read access to repository contents. If future steps need further access (such as posting checks, updating issues, etc.), they can be added to the permissions block, but for now, limiting to contents: read is the secure default. No methods, imports, or code logic change is required — only the YAML workflow file must be updated.

---

To fix this issue, an explicit permissions block should be added to the workflow YAML file. This block should be placed at the root of the workflow (i.e., before jobs:), so it apples to all jobs unless further overridden per-job. The permissions should be as minimal as required by the workflow. From the workflow code provided, the statuses: write permission is needed (the workflow sets commit status via API), and possibly contents: read if it needs to fetch the repository contents. Unless there's evidence the workflow needs other write-level permissions, the block
should specify:

permissions:
  contents: read
  statuses: write

This must be added on a new line after (or before) the name: and before the on: block. No additional imports or complex changes are needed; only a change to the YAML file.

---

To fix this, add a permissions block at the top-level of the workflow YAML (recommended), so it applies to all jobs unless overridden. The workflow does not perform any actions that require write privileges (e.g., modifying contents, issues, metadata, etc.). Therefore, the most restrictive and safe default is to set contents: read, which prevents the token from being used to make changes to the repository. This should be inserted directly after the name: declaration, before the on: block. No additional methods, imports, or code changes are needed—just an update to the YAML structure in .github/workflows/compute-rocm-dkmd-afar-trigger.yml.