On 12/31/25 1:24 PM, Jeffrey Law wrote:
On 12/31/2025 2:22 AM, Daniel Henrique Barboza wrote:
On 12/30/25 8:41 PM, Jeffrey Law wrote:
On 12/30/2025 6:29 AM, Daniel Barboza wrote:
Add a pattern to handle cases where we have an OP that is
unconditionally being applied in the result of a gcond. In this case we
can apply OP to both legs of the conditional. E.g:
t = b ? 10 : 20;
t = t + 20;
becomes just:
t = b ? 30 : 40
A variant pattern was also added to handle the case where the gcond
result is used as the second operand. This was needed because most of
the ops we're handling aren't commutative.
PR 122608
gcc/ChangeLog:
* match.pd (`(c ? a : b) op d -> c ? (a op d) : (b op d)`): New
pattern.
(`d op (c ? a : b) -> c ? (d op a) : (d op b)`): Likewise
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110701.c: the pattern added is now folding
an XOR into the ifcond and the assembler isn't emitting an
'andl' anymore. The test was turned into a runtime test
instead.
* gcc.dg/torture/pr122608.c: New test.
OK. So one thing did pop from that test. On xstormy16-elf I'm seeing:
/home/jlaw/jenkins/workspace/xstormy16-elf/gcc/gcc/testsuite/gcc.dg/torture/pr122608.c:
In function 'mulhighpart_test':
/home/jlaw/jenkins/workspace/xstormy16-elf/gcc/gcc/testsuite/gcc.dg/torture/pr122608.c:151:1:
error: type mismatch in binary expression
int
int
long int
t = t h* 2147483647;
With a similar error in mulhighpart_test2. It's saying we have an integer
output (t), integer input (t) and long integer input (2147483647). Not sure
how we got long int type here. But it's clearly unhappy.
Seems like xstormy16 is a 16 bit target and the literal I'm using in
the test (2147483647, or 0x7fffffff) is a long int in that context.
Duh. I should have remembered that.
I guess we should use something like (UINT_MAX >> 1) instead of 0x7fffffff.
I'll see if I can reproduce this error with xstormy16 and if the macro
fixes the problem.
No. This is not a test problem, this is a problem with the match.pd pattern.
Look at it this way, someone could have written the exact same code as you did
in that test and legitimately try to compile it. The compiler would then spit
out cryptic errors about inconsistencies in the internal intermediate format --
that's not reasonable behavior for the compiler.
This points to a problem either in the match part of the pattern or in the
simplification part of the pattern.
The message is indeed not user friendly. But I don't think it has to do with
the pattern being added here - I can get the same error in 'master', without
this
patch, and a small hack to reproduce it in a 64 bit host:
$ cat test2.c
__GIMPLE int multhighpart_test (int a)
{
_Bool b;
int t;
b = a > 0;
t = b ? 30 : 40;
// HACK: extra 'f' to go past INT_MAX for 64 bits
t = t __MULT_HIGHPART 0x7ffffffff;
return t;
}
$
$ ../build/gcc/cc1 -fgimple -O1 -dap -fdump-tree-optimized-details test2.c
multhighpart_testtest2.c: In function ‘multhighpart_test’:
test2.c:12:1: error: type mismatch in binary expression
12 | }
| ^
int
int
long int
t = t h* 34359738367;
Analyzing compilation unit
Time variable wall GGC
phase setup : 0.01 ( 69%) 1976k ( 90%)
TOTAL : 0.01 2186k
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
---------
I think we should proceed with amending mulhighpart_test.
And I'm not sure what the pattern can do in this case to prevent this from
happening. The user (in this case, the test) is trying to fit stuff that is
too big for the variable type the user is declaring, and that would happen
with or without the pattern being matched.
Thanks,
Daniel
jeff
