On 5/26/21 8:05 AM, Richard Biener wrote:
On Wed, May 26, 2021 at 1:37 PM Andrew Pinski <pins...@gmail.com> wrote:
On Wed, May 26, 2021 at 4:28 AM Richard Biener
<richard.guent...@gmail.com> wrote:
On Wed, May 26, 2021 at 1:07 PM Andrew Pinski <pins...@gmail.com> wrote:
On Wed, May 26, 2021 at 2:01 AM Andrew Pinski <pins...@gmail.com> wrote:
On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger
<bernd.edlin...@hotmail.de> wrote:
On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
From: Andrew Pinski <apin...@marvell.com>
Instead of some of the more manual optimizations inside phi-opt,
it would be good idea to do a lot of the heavy lifting inside match
and simplify instead. In the process, this moves the three simple
A?CST1:CST2 (where CST1 or CST2 is zero) simplifications.
OK? Boostrapped and tested on x86_64-linux-gnu with no regressions.
Differences from V1:
* Use bit_xor 1 instead of bit_not to fix the problem with boolean types
which are not 1 bit precision.
OK.
Thanks,
Richard.
Hmm, sorry, no luck.
I think this caused:
If anything it is a bad interaction with changes between r12-1046 and
r12-1053; I am suspecting a bug in those changes rather than my
changes causing the bug. Debugging it right now.
(gdb) p debug_tree(name)
<ssa_name 0x7ffff6a5cd38
type <boolean_type 0x7ffff6b45b28 _Bool public unsigned QI
size <integer_cst 0x7ffff6b2bdc8 constant 8>
unit-size <integer_cst 0x7ffff6b2bde0 constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7ffff6b45b28 precision:1 min <integer_cst
0x7ffff6b4a030 0> max <integer_cst 0x7ffff6b4a060 1>>
def_stmt _19 = ~_8;
version:19>
So what is happening is evrp converted:
ct_12 = ct_5 + -1;
Into
ct_12 = ct_5 == 1 ? 0 : 1;
(this was done before my patch)
Note this COND_EXPR is supposed to be combined
with its single use in a GIMPLE_COND ...
I Noticed it was not doing it (before my patch) inside evrp either.
I think it is at most done in forwprop, but even then it likely
lacks a fold pattern - we only seem to forward comparisons
into GIMPLE_CONDs explicitely, leaving the rest to
match.pd patterns.
And then it gets simplified to:
_8 = ct_5 == 1;
_19 = ~_8;
ct_12 = (int) _19;
(after my match.pd patch)
which this one then breaks. I suppose instead of replacing
ct_12 adjusting the GIMPLE_COND directly might be
a better approach ... or not folding the generated COND_EXPR.
I was going to try to see where COND_EXPR is created but it is late
and there seems to be other issues going on too.
For example, the above really should have been converted to:
_19 = ct_5 != 1;
ct_12 = (int) _19;
This might be a gimple-match issue where the conditional part is
always emitted without being simplified with the ~ part; COND_EXPR has
those kind of issues :).
No, we always re-simplify things, but there might be no
(bit_not (eq @0 integer_onep)) simplifier.
Oddly enough
_Bool foo (int x)
{
_Bool tem = x == 1;
return ~tem;
}
is simplified to return 1 via matching
/* Fold ~X op C as X op' ~C, where op' is the swapped comparison. */
(for cmp (simple_comparison)
scmp (swapped_simple_comparison)
(simplify
(cmp (bit_not@2 @0) CONSTANT_CLASS_P@1)
(if (single_use (@2)
&& (TREE_CODE (@1) == INTEGER_CST || TREE_CODE (@1) == VECTOR_CST))
(scmp @0 (bit_not @1)))))
Richard.
Which actually looks enticingly similar to what I'm seeing in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774.
IN that code,
Folding statement: _1 = ~b_6;
is not turning ~[1,1] into [0,0] but rather leaving it as varying. it
eventually fills the values in
_1 = 0;
if (_1 != 0)
goto <bb 4>; [INV
but it doesnt simply properly.
