PR功能描述 / 为什么需要这个合入：
本 PR 回移 GCC trunk 中以下三个 x86 向量化成本模型相关提交：

• https://gcc.gnu.org/g:9b9d605d68c
• https://gcc.gnu.org/g:4b2db744302
• https://gcc.gnu.org/g:a22b31304e0

对应的上游修改分别为：

• 9b9d605d68c: Cost truth_value exprs in i386 vectorizer costs
• 4b2db744302: Add --param ix86-vect-compare-costs
• a22b31304e0: Enable ix86-vect-compare-costs by default

该修改使 x86 向量化器默认比较不同候选向量模式的估算成本，并根据目标机 cost model 选择估算成本最低的候选模式。

在原有实现中，x86 后端虽然可以向 vectorizer 提供多个候选向量模式，但不会要求 vectorizer 比较这些模式的成本。这可能导致编译器保留较宽但实际成本更高的向量化方案，产生额外的 load、shuffle 或 vector epilogue。

同时，本 PR 为 truth-value expression 增加显式成本计算，避免在比较候选向量模式时将比较表达式作为普通向量语句计费。

如需恢复原有行为，可以使用：

  --param ix86-vect-compare-costs=0

在 c86-4g-m7 平台进行的 SPEC CPU2017 base、ref、1-copy 测试中，默认开启该功能后观察到整体性能提升(其中分别提升525(18.83%),527(3.72%),549(4.08%))。

相关 GCC 上游问题：

• PR tree-optimization/120398
• PR target/123603

希望检视人员了解的内容：

1. 本 PR 是三个 GCC trunk 提交的组合回移，不包含额外功能扩展。

2. 上游问题及新增测试：

   • costmodel-pr120398.c 对应 PR120398。该问题中，x86
     vectorizer 为两个有序浮点 reduction 选择较宽向量后产生大量
     shuffle，而对应的加法仍以标量形式执行。

     开启 vector mode cost comparison 后，编译器选择 8-byte
     vector，使两个 reduction 分别保存在两个浮点 lane 中，避免
     循环内不必要的 shuffle。

   • costmodel-pr123603.c 对应 PR123603。该问题表现为 SPEC
     CPU2017 548.exchange2_r 在 Zen4 上出现约 13% 的性能回退。

     对于 stride-9、每轮只处理两个相邻 int 的短循环，原实现
     选择 16-byte vector，需要额外的 vector load、permute 和
     epilogue。比较不同候选模式的成本后，8-byte vector 的估算
     成本更低。

   这两个测试均不显式指定：

   --param ix86-vect-compare-costs=1
   

   因此同时验证了该参数默认开启后的向量模式选择。
   3. GCC 12 分支测试适配：

   • costmodel-pr120398.c 根据 GCC 12 的 vectorizer dump 格式，
     检查：

     Choosing vector mode V8QI
     

   • costmodel-pr123603.c 使用：

     -mtune=c86-4g-m7
     

     以稳定复现 EulerGCC 12 分支和 c86 cost model 下的 8-byte
     vector 决策。

   • truth-value expression costing 按上游提交原样回移。对应上游
     提交本身未增加独立测试。

3. Alignment peeling 测试调整：

   vect-alignment-peeling-1.c 和
   vect-alignment-peeling-2.c 的 dump 扫描次数由 4 调整为 7。

   默认开启候选模式成本比较后，vectorizer 除 V4SF 外还会分析
   8-byte 候选模式。其中三个循环在分析较小候选模式时额外输出
   一次：

   Alignment of access forced using peeling
   

   因此 dump 中的记录数为：

   原有 V4SF peeling 记录：4
   新增 8-byte 候选记录：3
   总数：                 7
   

   最终每个循环仍选择 V4SF。使用 baseline 和 patched 编译器
   对比这两个测试生成的汇编，除编译器 .ident 信息外，汇编
   指令完全一致。

   因此该修改只调整候选模式分析产生的 dump 扫描次数，不代表
   实际生成了更多 alignment peeling 循环，也不改变最终代码生成。

4. Bootstrap 验证：

   测试源码：

   a1e85212064612612873b2a7c99456d956ca4af8
   

   主要配置：

   --enable-bootstrap
   --enable-checking=release
   --with-arch_64=x86-64-v2
   --with-tune=generic
   --disable-multilib
   --enable-languages=c,c++,fortran,lto
   

   构建命令：

   make -j32 bootstrap
   

   验证结果：

   • 构建退出状态为 0。

   • 三阶段 bootstrap 完成。

   • stage_current=stage3。

   • stage_final=stage3。

   • stage2/stage3 对象比较通过。

   • 最终编译器默认目标为：

     -march=x86-64-v2
     -mtune=generic
     

5. DejaGNU 回归验证：

   baseline：

   1448cecd0d080d0084746440ba14d9d189e2f0da
   

   patched：

   a1e85212064612612873b2a7c99456d956ca4af8
   

   两次构建除 prefix 和 pkgversion 外使用相同配置：

   --enable-werror
   --enable-checking=release
   --with-arch_64=x86-64-v2
   --with-tune=generic
   --disable-bootstrap
   --disable-multilib
   --enable-languages=c,c++,fortran,lto
   

   测试命令：

   make -j32 check-gcc
   

   测试结果：

   baseline g++.sum:
     PASS=229301 FAIL=9 XPASS=0 XFAIL=2065
     UNRESOLVED=1 UNSUPPORTED=10219
   
   patched g++.sum:
     PASS=229301 FAIL=9 XPASS=0 XFAIL=2065
     UNRESOLVED=1 UNSUPPORTED=10219
   
   baseline gcc.sum:
     PASS=178556 FAIL=25 XPASS=18 XFAIL=1432
     UNRESOLVED=14 UNSUPPORTED=6055
   
   patched gcc.sum:
     PASS=178562 FAIL=25 XPASS=18 XFAIL=1432
     UNRESOLVED=14 UNSUPPORTED=6055
   
   baseline gfortran.sum:
     PASS=66516 FAIL=0 XPASS=0 XFAIL=272
     UNRESOLVED=0 UNSUPPORTED=81
   
   patched gfortran.sum:
     PASS=66516 FAIL=0 XPASS=0 XFAIL=272
     UNRESOLVED=0 UNSUPPORTED=81
   

   contrib/compare_tests 结果：

   • 退出状态为 0。
   • gcc.sum、g++.sum 和 gfortran.sum 未发现新增回归。
   • patched-only unique FAIL：0。
   • baseline-only unique FAIL：0。
   • 新增测试产生 6 个预期 PASS。
   • alignment-peeling 的新扫描预期均通过。

6. 额外测试说明：

   在 native/c86-4g-m7 配置下，部分检查精确汇编形态或向量宽度
   的 scan 测试会因新的向量化决策发生变化。

   本 PR 的社区默认验证结论基于相同源码配置下的
   x86-64-v2/generic baseline 与 patched 对比，该配置未发现新增
   FAIL。

Checklist:
PR格式

• PR title是否和commit message title一致
• commit message是否使用模板，请配置git config commit.template .gitee/commit_message
• PR是否关联issue
• PR是否设置审查人员（主要成员ID为eastb233，李彦成，黄晓权）

功能验证

• 修改涉及后端架构
  • AArch64
  • X86_64
• GCC自举构建是否通过，参考[Wiki](https://gitee.com/openeuler/gcc/wikis/如何贡献 openEuler GCC 社区)
• GCC deja测试是否通过，并附上测试结果
  测试结果在上上述第六点:DejaGNU 回归验证