[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check
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
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
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
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
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
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
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
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.