[llvm] Stop failed SLP ordered reductions from starving the block

[Phil-amd]

Fixes #1273.

What. A new LLVM extension, slp-ordered-reduction-budget-refund, stops SLP's failed ordered-reduction attempts from using up the per-block scheduling budget. Since llvm/llvm-project@94e366ef2060, which is in our pin, SLP tries strict fadd chains as ordered reductions. In a large unrolled kernel every rejected attempt still charges slp-schedule-budget (100000 per block, never given back). Once that budget is spent, SLP can no longer schedule the profitable vectorization that comes after the attempts.

On MI355X, Primus-Turbo's rmsnorm_mxfp4_fused_kernel (32768×2880 bf16):

	Time	VGPR+AGPR	Spilled VGPRs
Before	297 us	512	346
After	152 us	220	0

The outputs are bit-identical.

The switch -fly-slp-ordered-reduction-refund is on by default. To turn it off for one kernel:

compile_hints={"llvm_options": {"fly-slp-ordered-reduction-refund": False}}

Why not disable-binop-extract-shuffle, the workaround proposed in #1273. It turns off a general VectorCombine fold, has to be set per kernel, and leaves the cause in place. Any large unrolled kernel can still lose the vectorization that follows a failed ordered reduction. The two combine well, though:

On this kernel	Time	VGPRs
This change alone	152 us	220
The workaround alone	140 us	238
Both	140 us	242 (same as 0.2.4)

With this change alone, a few cross-load packs remain, and that fold rewrites them into shuffles. That is why the workaround is still faster here.

Why the switch is on by default. CONTRIBUTING.md asks for an extension switch that is off by default. Keeping this one off would need FlyDSL to:

• set a global cl::opt on every compile;
• check that the LLVM in use registers the switch, which FLYDSL_LLVM_NO_EXT=1 builds and external LLVMs do not;
• accept that code calling gpu-module-to-binary directly gets no fix.

It can still be turned off without rebuilding LLVM, which is what the rule protects.

Key points

• Narrow trigger. It acts only when an ordered attempt in HorizontalReduction::tryToReduce vectorizes nothing. On gfx942, none of the 520 kernels compiled by tests/kernels change, and compile time is unchanged. With the switch off, the ISA is byte-identical to the 0.3.4.1 wheel's.
• Only the root is marked. A failed root is not retried. This follows llvm/llvm-project@1b10cd91, which also treats only the root of a failed ordered reduction as a dead end; its leaves stay valid roots. Marks are cleared at each new block.
• Not covered: the tryToReduceOrdered path.
• Upstream: not yet submitted, although CONTRIBUTING.md asks for that first. Upstream main still regresses on this kernel (116 spilled VGPRs).