On 8/31/23 11:57, Vineet Gupta wrote:
On 8/31/23 06:51, Jeff Law wrote:
On 8/30/23 15:57, Vineet Gupta wrote:
This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since the
pattern semantics can't be expressed by zicond instructions.
This involves test code snippet:
if (a == 0)
return 0;
else
return x;
}
which is equivalent to: "x = (a != 0) ? x : a"
Isn't it
x = (a == 0) ? 0 : x
Which seems like it ought to fit zicond just fine.
Logically they are equivalent, but ....
If we take yours;
x = (a != 0) ? x : a
And simplify with the known value of a on the false arm we get:
x = (a != 0 ) ? x : 0;
Which is equivalent to
x = (a == 0) ? 0 : x;
So ISTM this does fit zicond just fine.
I could very well be mistaken, but define_insn is a pattern match and
opt2 has *ne* so the expression has to be in != form and thus needs to
work with that condition. No ?
My point was that
x = (a != 0) ? x : 0
is equivalent to
x = (a == 0) ? 0 : x
You can invert the condition and swap the arms and get the same
semantics. Thus if one can be supported, so can the other as they're
functionally equivalent. It may be the at we've goof'd something in
handling the inverted case, but conceptually we ought to be able to
handle both.
I don't doubt you've got a failure, but it's also the case that I'm not
seeing the same failure when I turn on zicond and run the execute.exp
tests. So clearly there's a difference somewhere in what we're doing.
So perhaps we should start with comparing assembly output for the test
in question. Can you pass yours along, I'll diff them this afternoon
and see what we find.
jeff
