On Wed, Jun 17, 2026 at 6:27 AM Jeffrey Law <[email protected]> wrote: > > > > On 6/16/2026 8:52 PM, Zhongyao Chen wrote: > > This applies a default 2:1 scalar/vector unit ratio to integer vector > > body costs, which helps the cost model better match the actual hardware > > throughput. > > > > Take an int64 vadd at VLEN=128 for example: 4 scalar units and 2 vector > > units can both process 4 elements per cycle. Without this ratio, both > > vector and scalar stmts just get a cost of 1, which ends up making > > vectorization look too cheap. > > > > Skip applying this ratio for: > > - reduction stmts > > - gather/scatter stmts > > > > Since this is just an RFC patch, a few things need comments: > > > > 1. The ratio is hardcoded to 2 for now. > > - Should this come from the CPU model, tune info, or a param > > instead? I'm leaving it as is for future work. > > - How should we handle non-integer ratios like 3/2 ? > I was thinking about using issue rate from the tune structure as a > reasonable proxy for how wide the scalar part of the design. Then you > compare that to the VL of the code you want to vectorize. If the scalar > bandwidth is >= the number of vector elements you're handling per vector > op, then the scalar loop is probably preferred. It's not exact, but it > doesn't rely on magic numbers.
I think such scaling only applys to BB vectorization. For loop vectorization it might apply to the SLP subset of stmts, otherwise you are comparing vector loop vs. unrolled (with VF) scalar loop but in reality you'll end up with the not unrolled scalar loop where this simple mechanic falls apart. Not to mention that most (very) wide uarchs are frontend/renaming bottlenecked. Richard. > > Jeff
