[Bug target/114490] Optimization: x86 "shl" condition codes never reused

2024-03-28 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 --- Comment #7 from Kang-Che Sung --- I just come here to say that PR 114512 is the real issue that I wish to see fixed. It might be okay for me when the FLAGS of "shl" becomes unused by GCC, since other than CF (carry) and SF (sign) I don't

[Bug middle-end/114512] New: Optimization on "test if bit N is set" pattern ((C >> x) & 1)

2024-03-28 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114512 Bug ID: 114512 Summary: Optimization on "test if bit N is set" pattern ((C >> x) & 1) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

2024-03-27 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 Kang-Che Sung changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

2024-03-27 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 --- Comment #4 from Kang-Che Sung --- 1. I just read "AMD64 Architecture Programmer's Manual - Volume 3: General-Purpose and System Instructions"

[Bug web/114496] New: Documentation: "Non-Bugs" page should update/mention something about -Wsign-conversion

2024-03-27 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496 Bug ID: 114496 Summary: Documentation: "Non-Bugs" page should update/mention something about -Wsign-conversion Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

2024-03-26 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 --- Comment #3 from Kang-Che Sung --- (In reply to Andrew Pinski from comment #2) > > Basically if you are shifting by 0, then the CF bit never changes from the > previous and this can't be done. > > So the comment in the backend is correct

[Bug target/114490] New: Optimization: x86 "shl" condition codes never reused

2024-03-26 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 Bug ID: 114490 Summary: Optimization: x86 "shl" condition codes never reused Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers

2024-03-20 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 --- Comment #4 from Kang-Che Sung --- (In reply to Xi Ruoyao from comment #2) > *** Bug 114406 has been marked as a duplicate of this bug. *** I can't say bug 114406 is an exact duplicate of this one. Although my report mainly addresses right

[Bug middle-end/114406] New: Optimizations with ">>", div, mod and mul where operands are all positive

2024-03-20 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114406 Bug ID: 114406 Summary: Optimizations with ">>", div, mod and mul where operands are all positive Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity:

[Bug tree-optimization/114341] Optimization opportunity with {mul,div} "(x & -x)" and {<<,>>} "ctz(x)"

2024-03-15 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341 --- Comment #3 from Kang-Che Sung --- I missed one case that is more obvious: (1 << __builtin_ctz(y)) == (y & -y) Multiplication is not needed in this case, and thus (1 << __builtin_ctz(y)) can simplify to (y & -y). (I didn't think of a reason

[Bug rtl-optimization/114338] Optimizing (x & (-1 << y)) to ((x >> y) << y) or vice versa

2024-03-15 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338 --- Comment #6 from Kang-Che Sung --- (In reply to Richard Biener from comment #5) > For canonicalization the BIT_AND variants might be preferable since they > possibly combine with other logical ops. Also more constant operands > when the

[Bug tree-optimization/114341] New: Optimization opportunity with {mul,div} "(x & -x)" and {<<,>>} "ctz(x)"

2024-03-14 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341 Bug ID: 114341 Summary: Optimization opportunity with {mul,div} "(x & -x)" and {<<,>>} "ctz(x)" Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity:

[Bug rtl-optimization/114338] (x & (-1 << y)) should be optimized to ((x >> y) << y) or vice versa

2024-03-14 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338 --- Comment #3 from Kang-Che Sung --- (In reply to Jakub Jelinek from comment #2) > Bet the point of this PR is to canonicalize in GIMPLE to one of the forms > (both have the same number of GIMPLE statements, so that makes it harder to > pick

[Bug rtl-optimization/114338] New: (x & (-1 << y)) should be optimized to ((x >> y) << y) or vice versa

2024-03-14 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338 Bug ID: 114338 Summary: (x & (-1 << y)) should be optimized to ((x >> y) << y) or vice versa Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug rtl-optimization/114087] New: RISC-V optimization on checking certain bits set ((x & mask) == val)

2024-02-24 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087 Bug ID: 114087 Summary: RISC-V optimization on checking certain bits set ((x & mask) == val) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/113680] Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0

2024-01-31 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 --- Comment #3 from Kang-Che Sung --- Oops. I made a typo in the test code. func4() shouldn't have that redundant brace. The corrected example: ``` void func4(int x, int y) { int diff = x - y; if (diff > 0) putchar('>');

[Bug middle-end/113680] Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0

2024-01-31 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 --- Comment #2 from Kang-Che Sung --- I forgot to mention that such optimization is unsafe for floating points (actually I knew that when I write my code). `(a - b) < 0` optimization shouldn't be performed with unsigned integers either. I

[Bug rtl-optimization/113680] New: Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0

2024-01-31 Thread Explorer09 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 Bug ID: 113680 Summary: Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0 Product: gcc Version: 13.2.0 Status: UNCONFIRMED