tree 7128f839cbec2a9d8560270953172137476f7e07
parent bff05a9dba76027d6145006d3f987f4e1da038cc
author Ege Beysel <beysel@roofline.ai> 1786642821 +0200
committer GitHub <noreply@github.com> 1786642821 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJqfgGFCRC1aQ7uu5UhlAAAyIUQAJA4N05WEYjUdBLs5TsvsXth
 mDinTrK8+1eKn7rTGZMYSQSVM1CB3BACUUZWM9xfY95RdBdsJsefbOW8sugk1cWj
 RHDrJRME+QbmOL4Vai37Sg9+dBwbSu8bIgmQqfePVweBCMExUNwn4WWI2M7B0boR
 fTsd+KXAiNGUuFcubOqYKvhpr133nvaNT8duC+DB/0D7pNcqRDuODocaN4fTPB3p
 8BpJDxY6IablEdOc//WWFgFNChu7N42ZVkPGmsI1b0hlv6qqP+wDpDqve+468Xm9
 DnA6RvN2LgOc7e6dm2GhgwaPi4BWFh3PJoNIE4siUHdkk3oZT6Rg5vJsLijJWzmf
 c7oj74Hco+w9s4IZ1jkRIacQX+z6WBT/MQ+4IEuTy+88sG3SPl48WW6vApUnh0Z5
 eUjbZpcB43xb0gWztEYLi6ETvogAU10YiFbRe5m1P4CWMGqBWS3VwiY1WolchUKe
 s/kMInuO/D2/6NmH92+GMgxFMpi36nNShDU9VZhVSQya8w0yA+f3kEKVZbcyBZl+
 9xETlj1+/0KFtk4yLIJ/1s6GbB2H9cH5Q8aflrDf1hQWVq4JT/ECqtLs4ddKAbm1
 RPpM7m7rvEFOnr+LEw9QRI13fnjjliPoYCKp1W4bh80dUivcbw1C0o3traDl6w0f
 pdKHsF+tFsTdo7crrGTo
 =/dpj
 -----END PGP SIGNATURE-----
 

[Codegen][LLVMCPU] Split loadProcessorData: hoist only the alloca (#24786)

35b2070 (#24749) fixed unbounded stack growth by moving the whole
loadProcessorData CPU-feature patch buffer construction to the function
entry block. But that also hoisted the feature-bit or/store away from
the ukernel call, and once the ukernel inlines, LLVM can no longer
store-to-load forward the forced feature bits into the ukernel's runtime
feature check across the enclosing loop, so the mmt4d/pack tile-func
select never devirtualizes and the microkernel is left out-of-line.

Split the two concerns: reserve only the alloca (the stack slot, the
actual cause of #24744) in the entry block, but keep the feature-bit
patch at the call site. The stores re-run per iteration but allocate no
stack, so the stack stays bounded while the forced bits remain adjacent
to the (inlined) load and fold as before, restoring devirtualization.

Assisted-by: Claude-Code

---------

Signed-off-by: Ege Beysel <beyselege@gmail.com>