Hi Jeff > Wangjue -- there's nothing inherently wrong with the testcase > adjustments, but we prefer to have at least some understanding of why > the test was changed.
> If the code vectorized before with the cost model, but doesn't vectorize > after your change with the default cost model *and* the code is likely > profitable to vectorize, then you're introducing a code quality regression. > If the code isn't likely to be profitable with vectors, then your change > is good and exhibits the behavior we'd want to see. > So that's really the key thing we want to understand -- is the testsuite > change covering up a code quality regression or is it the case that the > code isn't profitable to vectorize and thus turning off the cost model > to force vectorization is the right thing to do for the test. These tests check SAT_TRUNC recognition and the expected vnclipu instructions. I added -fno-vect-cost-model because a downstream build configured with --with-tune=xt-c950 rejected both loops. The intent was to keep the instruction checks independent of tuning, though this also reduces coverage of vectorization decisions under the default cost model. I rechecked both tests on the same upstream baseline, with and without the patch. Without disabling the cost model, both vectorize and produce identical assembly. The option changes are therefore unnecessary for the upstream configurations checked. Would you prefer that I drop these two option changes and keep the original test options? Thanks, Wangjue
