jpolo1224 dfb4263926 Android: regenerate the PGO profile against this tree, and let generate mode run ...

The committed profile was generated from ARMSX2-mono-recovered and last refreshed
on 2026-07-13 -- its own function paths name that tree. Building against it costs
7.7% of .text (15,262,600 -> 16,433,556 bytes) versus a matched profile, because
every function the profile does not cover falls back to static inlining
heuristics. Size is the visible symptom; the risk is speed, and this is the same
class of defect as the #165 VU slam, where a profile predating recompiler churn
made LTO optimise the hot VU paths the wrong way.

This one is captured from armsx2-push-staging at e9f8f8366 -- the first profile
ever taken from the tree it is used to build. 38,219 functions against the old
profile's 36,807, with microVU (292 entries), recExecuteBlock, the recompiler
dispatchers, GSRendererHW::Draw and the VIF/GIF transfer loops all covered.
Rebuilding with it lands .text at 15,173,960, 0.6% BELOW the last known-good
build despite carrying more code -- a matched profile inlines selectively where
an unmatched one inlines blindly.

build-release-apk.sh required PROF unconditionally, which made regenerating
impossible: PGO_MODE=generate builds the instrumented APK you play in order to
CREATE a profile, so demanding one up front failed instantly with a FATAL naming
a file that run never reads. Require it only in optimize mode.

2026-08-09 21:53:50 -04:00

..

armsx2.profdata

…