https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126887
Bug ID: 126887
Summary: backward threader cannot peel a single-iteration loop
that the DOM threader peels
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: amacleod at redhat dot com, rguenth at gcc dot gnu.org
Target Milestone: ---
I’ve been going through testcases that fail with —-param=dom-jump-threading=0
to see what fails, as a first stab at seeing what optimizations are missing or
what testcases need adjusting.
For the record, I’ve been using Claude Fable to help categorize these failures,
and I haven’t dug into them as much as I would’ve otherwise.
Here is a distilled failing testcase:
/* { dg-do compile } */
/* { dg-options "-O2 --param=dom-jump-threading=0
-fdump-tree-threadfull2-details" } */
/* When flag != 0, i enters the loop as 0 and the loop runs exactly
once, so the entering path resolves the exit test and the first
iteration can be peeled. DOM's threader peels it (dom3, once
PROP_loop_opts_done lifts the crossing-loops restriction); the
backward threader refuses the resolvable path through the
preheader by design (the pr14341 loop_father restriction in
find_paths_to_names) and only ever explores the latch predecessor.
With DOM threading disabled, no thread is registered at all. */
volatile unsigned sink;
void
f (int flag, unsigned n)
{
unsigned i = flag ? 0 : n;
do
{
sink = i;
i += 4;
}
while (i != 4);
}
/* { dg-final { scan-tree-dump-times "Registering jump thread" 1 "threadfull2"
} } */
These are the failing testcases that I believe are due to the above:
gcc.dg/vect/vect-54.c
gcc.dg/vect/vect-31-big-array.c (ppc64le only -- passes on x86_64 current
trunk)
gcc.dg/uninit-1.c (bogus warning at any -O)
gcc.dg/auto-init-uninit-1.c (same)
What do we want to do here?
