nx_divprobe.nx

nx_divprobe.nx -- DOES nx_cc STRENGTH-REDUCE DIVISION BY A CONSTANT POWER OF TWO? WHY THIS PROBE EXISTS. A render-performance lane measured gs_resolve at 12.3 ns/pixel while doing six divisions by 256 -- a power of two -- and concluded from an OUTLINE GREP that the x86 backend has no strength-reduction pass. That is an absence claimed from a FILTERED READ, which this estate does not accept as evidence: a grep that finds no function named "shr" cannot see a shift emitted inline, and would report the same nothing either way. Before any compiler is edited on the strength of that claim, the claim itself gets an instrument. THE EXPERIMENT DISCRIMINATES, which is the only reason to run it. Three loops, identical in every respect except the arithmetic in the hot line: A: / DP_POW2 -- divisor IS a power of two, so a strength-reducing compiler emits a shift B: / DP_NOTPOW2 -- divisor is one less, NOT a power of two, so no compiler can avoid the idiv C: * DP_MUL -- a multiply, the cost floor for "arithmetic that is not division" If A is much faster than B and close to C -> strength reduction EXISTS; the rung is REFUTED. If A and B are alike and both far above C -> no strength reduction; the rung is CONFIRMED. Either outcome is a result. The probe is written to be unable to flatter the answer it was built hoping for: the two divisors differ by one, so nothing but the power-of-two property distinguishes them, and the accumulator is PRINTED so no loop can be optimised away as dead. DP_ITERS is DERIVED, not picked: the clock is microsecond-resolution, and a measurement worth trusting needs to exceed that by a wide margin, so the loop runs long enough that each arm takes order-milliseconds. The three arms share one iteration count so their times are directly comparable.