Fr0zka
7189d51b7b
The inlining experiment partitioned everything, just not along the axis it was framed on: inlined != FORCENOINLINE : 0 inlining is not the variable FORCENOINLINE == op stack : 5000/5000 test-TU carve == other-TU op, always inlined == verbatim : 4874/5000 126 differ, in the SAME TU The test-TU carve matches the operator stack across a TU boundary perfectly and disagrees with the verbatim inside its own TU, so neither TU nor inlining is it. Sorting the five implementations by the one remaining difference splits them exactly: A (GetMazeDensity) and C (verbatim) hold Blend as a compile-time constant; B (FSdfCarveOp, a member) and both parameter versions hold it as runtime data. A == C, B == Inl == Noi, and the groups differ. Every observation today fits that and nothing else does. Mechanism: under /fp:fast, folding Blend * 2.0f to the literal 4.0f enables a contraction in SmoothStep01's 3.0f - 2.0f*x -- one rounding instead of two -- that the runtime form cannot get. This matters beyond the bug: an op's parameters are DATA by design, which is the entire point of the refactor, so they can never be compile-time literals again. The ULP difference is therefore inherent and permanent for every archetype port, and no care in transcription will remove it. That is the real reason bit-identity is unachievable here -- the earlier /fp:fast note named the right compiler flag for the wrong reason. CarveConstBlend added: identical to CarveInlined except Blend is a compile-time constant. Predicted to match the verbatim 5000/5000 and differ from the runtime form on exactly 126. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>