On 9/28/26 11:48 PM, Tamar Christina wrote:
-----Original Message-----
From: wangjue <[email protected]>
Sent: 10 September 2026 09:14
To: [email protected]
Cc: [email protected]; [email protected];
[email protected]; [email protected]; juewang
<[email protected]>
Subject: [PATCH v2] vect: Look through promotions for SAT_TRUNC
From: juewang <[email protected]>
Use a single-use unpromoted input when MAX_EXPR and SAT_TRUNC are
supported for the narrower type, avoiding a redundant widen-and-narrow
sequence.
The test cases were generated by an LLM.
Assisted-by: GPT-6
Regtested on rv64gcv, rv32gcv, x86_64 and aarch64 with no regressions.
Changes since v1:
v2: Update the test cases for the upstream canonicalization changes.
v1: Add vect_sat_trunc_clip_input_vectype to check target support.
Use the appropriate gimple_build_assign overload for MAX_EXPR.
Vect parts are OK. You need a RISCV maintainer for the tests.
Missed those. THanks for calling them out.
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.
Jeff
