On 7/10/2026 6:55 AM, Richard Biener wrote:
On Thu, Jul 9, 2026 at 4:15 PM Jeffrey Law <[email protected]> wrote:
On 7/7/2026 11:13 AM, Kael Andrew Franco wrote:
From cf6e4302cddd979315a58008e77f0c869280318c Mon Sep 17 00:00:00 2001
From: Kael Andrew Alonzo Franco <[email protected]>
Date: Tue, 7 Jul 2026 13:09:01 -0400
Subject: [PATCH] match: Use tree_expr_nonnegative_p for (X / Y) (==,!=) 0 -> X
(<,>=) Y [PR125738]
TYPE_UNSIGNED did not cover non-negative X and Y so use tree_expr_nonnegative_p
to relax condition on optimizations.
gcc/testsuite/gcc.dg/tree-ssa/pr64130.c fails because match.pd optimize
funsigned () before
evrp pass. Fix this by removing funsigned () and one scan-tree-dump.
Bootstrapped and tested on x86_64-pc-linux-gnu.
PR tree-optimization/125738
PR tree-optimization/64130
gcc/ChangeLog:
* match.pd: Use tree_expr_nonnegative_p for (X / Y) (==,!=) 0 -> X
(<,>=) Y.
gcc/testsuite/ChangeLog:
* gcc.dg/pr125738.c: New test.
* gcc.dg/tree-ssa/pr64130.c: Remove scan-tree-dump [2, 8589934591].
(funsigned): Remove.
(funsigned2): Rename to funsigned.
So conceptually good. Throwing it into an LLM did uncover one concern
worth relaying.
In particular the old code checked TYPE_UNSIGNED, so it'd work for
vector types. tree_expr_nonnegative_p always returns false for
vectors. So we could end up with a code quality regression here (and
other places where we've converted to tree_expr_nonnegative_p).
So I think there's a question here. Do we want tree_expr_nonnegative_p
to return tree for vector types that are unsigned. Conceptually that's
a good thing, but may have unintended consequences elsewhere. If no,
then we probably want to use something like like TYPE_UNSIGNED ||
tree_expr_nonnegative_p in a test rather than in the capture. I'd tend
to lean towards the former, but that' s without any real investigation.
A much smaller issue. I would have at least considered leaving the
original funsigned test in place and instead checked the dump for the
optimized form. It essentially turns into an additional test to this
patch. But again, this is small.
Richi, Andrea thoughts?
I think it returns true even for unsigned vectors via the
tree_single_nonnegative_p fallthru for SSA_NAME.
So I'm not entirely sure what I was looking at yesterday; I know after
seeing that from the LLM I dove into what I thought was
tree_expr_nonnegative_p thinking that the LLM must have been wrong. What
I saw had a early out based on types. But looking today after your
message, I don't see that structure. The only conclusion I can come to
is I was in the wrong routine or looking at some old bits (I was
wandering as far back as gcc-13). Too many machines, too many source
trees...
Anyway, I'll pick this back up for Kael.
jeff
