On 1/13/25 7:47 AM, Richard Biener wrote:
On Mon, 13 Jan 2025, Richard Biener wrote:
The following makes niter analysis recognize a loop with an exit
condition scanning over a STRING_CST. This is done via enhancing
the force evaluation code rather than recognizing for example
strlen (s) as number of iterations because it allows to handle
some more cases.
STRING_CSTs are easy to handle since nothing can write to them, also
processing those should be cheap. I'd appreciate another eye on
the constraints I put in.
Note to avoid the -Warray-bound dianostic we have to early unroll
the loop (there's no final value replacement done, there's a PR
for doing this as part of CD-DCE when possibly eliding a loop).
This works for strings up to 8 chars (including the '\0') only
(rather than 16, the unroll niter limit) because unroll estimation
will not see that the load from the string constant goes away.
Final value replacement doesn't work since ivcanon is now after it,
it's not the time to move the pass though. The pass is in theory
supposed to add a canonical IV for the _by_eval cases, but we
didn't "fix" this when we added cunrolli (we probably should have
moved ivcanon very early, or made cunroll add such IV if we
used _by_eval but did not unroll).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Some testsuite adjustments are necessary, but the following followup
handles enabling final value replacement by forcing a canonical IV
from cunrolli when we didn't unroll but used force-evaluation to
compute niter. It also makes us handle the new testcase which ends
up with POINTER_PLUS_EXPR for the inital value.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Any thoughts?
Thanks,
Richard.
From 705a287694404aafa72bbdc9da21dd1bf448cd85 Mon Sep 17 00:00:00 2001
From: Richard Biener <rguent...@suse.de>
Date: Mon, 13 Jan 2025 15:39:07 +0100
Subject: [PATCH] tree-optimization/92539 - handle more cases
To: gcc-patches@gcc.gnu.org
The following ontop of the previous fix also handles POINTER_PLUS_EXPR
of &"Foo" and a constant offset as happens for the added testcase
as well as making sure to add a canonical IV when we figured niter
by force evaluation during cunrolli so that work isn't wasted,
DCE can eliminate the load and SCCP perform final value replacement.
PR tree-optimization/92539
* tree-ssa-loop-ivcanon.cc (canonicalize_loop_induction_variables):
When niter was computed constant by force evaluation add a
canonical IV if we didn't unroll.
* tre-ssa-loop-niter.cc (loop_niter_by_eval): Use
split_constant_offset to get at a STRING_CST and an initial
constant offset.
* gcc.dg/tree-ssa/sccp-16.c: New testcase.
The ivcanon code looks reasonable in isolation, so no worries there if
you're happy with the extra recorded IV. The niter code just
generalizes some existing bits slightly.
So as long as you're happy with the ivcanon bits, I think it's reasonable.
jeff
