On 7/17/2026 1:30 AM, wangjue wrote:
Hi Jeff
What doesn't make sense to me is if x86, power and s390 have the same
basic code in place to unroll small loops, why are they not failing?
While we can add an rv64 optimization adjustment to this test, I'd like
to understand why risc-v is behaving differently first.
Thank you for the reminder.you're right that this isn't really about the
small-loop
unrolling itself. I dug into it, and the difference comes down to the
handling of flag_cunroll_grow_size.
Root cause
----------
At -O2 RISC-V enables -funroll-loops together with
-munroll-only-small-loops. As a side effect of generic option
processing, that combination also turns on flag_cunroll_grow_size, and
RISC-V never overrides it. With flag_cunroll_grow_size enabled,
tree-cunroll is allowed to completely unroll the CRC-like loop in
vrp91.c even though doing so grows code size.
Once the loop is fully unrolled, there is no loop and therefore no
induction variable left. VRP derived the expected [0, 7] range from
that induction variable, so with the loop gone the range simply never
shows up in the vrp2 dump -- hence the regression.
Why x86, Power and s390 don't regress
-------------------------------------
They all reset flag_cunroll_grow_size in their
TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hooks, unless one of the following
holds:
- unrolling was explicitly requested,
- loop peeling is enabled, or
- the optimization level is -O3.
Fix
---
I added the equivalent flag_cunroll_grow_size handling for RISC-V:
- the reset logic is invoked from riscv_option_override, and
- it is also registered as TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE, so
that function attributes and #pragma optimize are handled
consistently (not just the command-line options).
I'll send the updated patch shortly.
Thanks for chasing this down. The updated patch is in my queue.
jeff
