On 7/14/2026 8:19 AM, Dusan Stojkovic wrote:
> Note that canonicalization is driven more by the SSA_NAME_VERSION and IL
> structure than types and getting things in the right form to expose this
> case may be hard.
>
> One approach I've taken through the years is to sketch out such a
> pattern and have it abort() when it matches.  Then I run a large
> codebase through that compiler to see if I can get it to trigger that
> abort.  Much like basic pattern development, I often start with a
> simplistic, over-matching pattern and refine.  That makes it less likely
> that a logical big preventing a match makes me conclude the pattern is
> unnecessary/worthless.  Assuming that process finds a real trigger, I
> then reduce it and include going forward.
>
> It's not critical for this patch IMHO, but perhaps an avenue to explore
> in the future.  Based on Andrea's comments, I suspect we're in agreement
> on that.

As I mentioned, usually I just try different combinations of the same
testcase to see if it behaves differently, but your suggestion makes a
lot of sense too, though I haven't tried it for this version of the
patch.

> Don't the tests in the IF clause result in type <= ltype0 <= ltype1, yet
> in the WITH clause we're assigning largertype to ltype0.  Something
> seems wrong with that.

Yes, and now that you mention it largertype does seem redundant. I
removed it in this version and used @4 (associated with ltype1) instead
of @1.

> Your scan-assembler-times tests are a bit inconsistent in that they
> don't anchor with a tab before or after the opcode with any
> consistency.  We're not terribly good about this in the testsuite, so
> it's not a major problem, though we should try to be consistent within
> any given test if we can.

I added the tab at first to differentiate between andi and and, so now I
have it on all scan-assembler-times tests for consistency.
Also, I tweaked the values in the testcase b a bit because for some
reason the assembly generated for rv32 wasn't branchless. It is
branchless now.

> Overall I think you're on the right track here.  As I mentioned in the
> call last week, it's great to see this coming together after years of
> banging our heads on the wall.
>
> Jeff

Glad to help,
Dusan

 2026-07-14  Dusan Stojkovic  <[email protected]>

      PR target/123883

gcc/ChangeLog:

      * match.pd: New pattern.

gcc/testsuite/ChangeLog:

      * gcc.target/riscv/pr123883.c: New test.
Co-authored-by: Jeff Law <[email protected]>
This looks good.  I guess the only question is whether or not to add the :c to the bit_and to allow it to match both forms.  I realize that without a testcase we're not going to test the alternate form, but looking at the pattern I don't see any real reason for the other form to show up.  So I'm going to include the :c.

I'll do another bootstrap & regression test on x86-64 since mine ran without the :c.  I'll also do spot testing of riscv32-elf and riscv64-elf.  Assuming that's clean, I'll push it later today.

jeff


Reply via email to