perf(amdgpu): amdgpu perf + force_inline

[deepsek]

• kernel launch improvements
• force_inline support into the AST

[deepsek]

/run-ci

[yaoliu13]

Thank you

[yaoliu13]

/run-ci

[yaoliu13]

/run-ci

[lohiaj]

Strong evidence to land. AMDGCN dumps on gfx942 from the Genesis hot kernels show the launcher kernels are thin (≤74 VGPR, 0 scratch) but each calls an outlined function_body via s_swappc_b64 that pays a fixed callee-save prologue/epilogue:

outlined function_body in	VGPR	AGPR	callee-save scratch
func_solve_body_monolith_kernel_1	256	172	1012 B (252 dwords)
func_solve_init_kernel_11	248	32	284 B
func_solve_init_kernel_7	248	32	292 B
kernel_step_1_kernel_26	248	32	240 B

Prologue in each is ~60 contiguous scratch_store_dwords + ~32 v_accvgpr_write_b32s saving v40..v207 in 8-VGPR groups; epilogue mirrors. ~184 prologue/epilogue ops every call.

Confirmed via paired AMDGCN dumps that source-level changes don't clear this floor: e.g. a loop-fusion candidate that cut -690 asm lines from function_body left ΔVGPR/ΔAGPR/Δscratch = 0. Whatever shrinks the body still saves the same registers across the call boundary.

force_inline on the relevant @qd.funcs removes that boundary entirely. Happy to share the full dumps for any of the above kernels if useful

@yaoliu13 @deepsek FYI

[deepsek]

Good eye @lohiaj! That's the main reason I'm exposing this as a variable.. Thanks for validating the same too!
A fun little exercise would also be to see why i'm exposing it as a loop_config decorator instead of qd.func..
In any case, waiting for this to land finally so that the other side of the spectrum can have it's light of day!

[deepsek]

/run-ci

[deepsek]

/run-ci

[yaoliu13]

1370057 and 4968

[yaoliu13]

LGTM

[yaoliu13]

Need one more approval

[lohiaj]

reviewed and approved, force_inline removes the outlined callee save restore boundary i validated on the genesis hot kernels and the launcher hot path cleanup looks clean

[yaoliu13]

/run-ci

[yaoliu13]

/run-ci