[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2023-08-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

--- Comment #8 from Andrew Pinski  ---
I have a patch which converts this into:
  _1 = x_4(D) < 0;
  _2 = y_5(D) <= 0;
  _3 = _1 ^ _2;

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2023-08-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> 
> Something like:
> Prefer ^ over ==
> ```
> (for cmp
> (for cmpN
> (for neeq
>  (simplify
>   (neeq:c (cmp @0 @1) @3
>   (if (cmpN == inverseof(cmp, TREE_TYPE (type))
>(bit_xor (cmpN @0 @1) @3)
>   )
>  )
> )))
> ```

Actually we can just do:
```
/* For CMP == b, prefer CMP` ^ b. */
(for neeq (ne eq)
 (for cmp (tcc_comparison)
  (simplify
   (neeq:c (cmp@0 @1 @2) @3)
   (bit_xor (bit_not! @0) @3)
  )
 )
)
```
Since we already have folding of (bit_not cmp) in another place.

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2023-08-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
*** Bug 107881 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2023-06-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

--- Comment #5 from Andrew Pinski  ---
  _1 = x_4(D) >= 0;
  _2 = y_5(D) <= 0;
  _3 = _1 == _2;

Something like:
Prefer ^ over ==
```
(for cmp
(for cmpN
(for neeq
 (simplify
  (neeq:c (cmp @0 @1) @3
  (if (cmpN == inverseof(cmp, TREE_TYPE (type))
   (bit_xor (cmpN @0 @1) @3)
  )
 )
)))
```

This is what clang seems to do rather than any magic around == really.

I do wonder if we should try to expand bool == bool as bool^bool^1 .

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2021-10-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101807

--- Comment #4 from Andrew Pinski  ---
related to PR 101807

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2021-10-04 Thread arjun.is at lostca dot se via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

Arjun Shankar  changed:

   What|Removed |Added

 CC||arjun.is at lostca dot se

--- Comment #3 from Arjun Shankar  ---
If the code is compiled as C, gcc produces essentially the same code as clang
with some differences in the schedule of instructions:
https://godbolt.org/z/8nsq16Pen

It's when the code is compiled as C++ that gcc does worse:
https://godbolt.org/z/dK8hTEhjr

The difference lies in the front-ends. The C front-end already appears to know
that this is a XOR. testcase.c.004t.original looks like:

  return (int) (x < 0 ^ y <= 0);

On the other hand, g++ outputs:

  return  = x >= 0 == y <= 0;

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2020-05-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

--- Comment #2 from Richard Biener  ---
Btw, thanks for all these bugreports!

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

2020-05-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||easyhack,
   ||missed-optimization
   Last reconfirmed||2020-05-18
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.