Hi Jeff, I traced these option changes back to testing a downstream compiler configured with --with-tune=xt-c930. With the original options (-O3 -march=rv64gcv -mabi=lp64d), both pr120378-3.c and pr120378-4.c are rejected by its cost model. I reproduced the following diagnostic:
Vector inside of loop cost: 14 Scalar iteration cost: 6 vectorization factor = 2 not vectorized: vectorization not profitable. Adding -fno-vect-cost-model makes both tests vectorize and emit the expected three and two vnclipu.wi instructions, respectively. Using -mtune=generic-ooo with the same compiler also makes both vectorize without disabling the cost model. The option was added to keep these instruction-selection tests independent of that tuning choice, and I carried the changes into the upstream submission. To check your concern, I reran both tests using the saved upstream baseline e90e0f66051d and the same baseline with this middle-end change, without -fno-vect-cost-model. With the configured default tuning, -mtune=generic-ooo, and -mtune=sifive-p670, both tests vectorize before and after the patch. The before/after assembly is identical for each test and tuning choice, including the expected vnclipu.wi counts. So there is no loss of vectorization for these two tests in the upstream configurations checked. The option changes are unnecessary there; I propose leaving these two existing tests' options unchanged in the upstream patch. I have not measured hardware profitability for the xt-c930 case, so I cannot conclude that its cost-model decision is correct from this test alone. Thanks, Wangjue
