On 10/14/26 11:23 AM, Avinal Kumar wrote:
+
+/* Verify the left shift path of the same pattern also works for 128-bit
+ types. The mask isolates only the shifted bits, so the redundant lower
+ bits can be folded into the mask. */
+__int128 f3(__int128 a) { return (a << 120) & ((__int128)0xff << 120); }
+
+/* f1, f2: arithmetic right shifts should be converted to logical shifts. */
+/* { dg-final { scan-tree-dump "uint128_t" "optimized" } } */
+
+/* Verify 64-bit case also works, this is folded by C frontend putting it
+ here as regression guard. */
+long long f4(long long a) { return (a >> 63) & 1; }
+
+/* All BIT_AND masks should be folded away. */
+/* { dg-final { scan-tree-dump-not "& 1" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "& 255" "optimized" } } */
The test seems a bit weak. f1 and f2 both generate a AND expression in
the .optimized dump without your patch. So you can correctly infer your
optimization fired for those. However f3/f4 do not seem to be covered
as I don't see any AND expressions in their .optimized dump without your
patch. Finding a way to verify the f3/f4 cases seems like the only
blocking issue.
Good catch, I included f4 as regression guard but I guess it wasn't
useful. So I looked into it and here are some options:
1. I can check explicitly for optimized forms, something like:
- for f3: "... 120" "optimized" // shift with no AND
- for f4: ">> 63" "optimized" // confirm the shift survived
Certainly possible. You may need to split them off into a distinct
testfile so you can match what you need in one or both of these without
being influenced by f1 or f2. Thanks for trying to cover the negative
cases, it's a space I think the whole project could do better about.
or
2. find more mask widening cases and replace f3 and f4 with that
Possible as well, but if #1 works this would seem like it doesn't
provide any value. If you do want to explore this space, you might see
if you can get the LLM to generate a test rather than trying to cobble
up one on your own. I had some success with that last weekend for a
pretty obscure failure in the RISC-V backend. In my case we likely
wouldn't use the test -- it requires a bit of hackery to actually set up
and run the test and my goal was really just to prove the pattern was
buggy in the suspect way.
or
3. Just drop f3 and f4 as the required case is covered with f1 and f2.
Probably the least desirable.
jeff
