public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 [not found] <bug-90094-4@http.gcc.gnu.org/bugzilla/> @ 2021-07-25 1:06 ` pinskia at gcc dot gnu.org 2023-06-14 6:11 ` eggert at cs dot ucla.edu ` (2 subsequent siblings) 3 siblings, 0 replies; 4+ messages in thread From: pinskia at gcc dot gnu.org @ 2021-07-25 1:06 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Component|rtl-optimization |middle-end --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Note I noticed clang turns __builtin_sub_overflow case into the code for the == LONG_MIN case. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 [not found] <bug-90094-4@http.gcc.gnu.org/bugzilla/> 2021-07-25 1:06 ` [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 pinskia at gcc dot gnu.org @ 2023-06-14 6:11 ` eggert at cs dot ucla.edu 2023-06-14 8:58 ` jakub at gcc dot gnu.org 2023-06-14 9:00 ` jakub at gcc dot gnu.org 3 siblings, 0 replies; 4+ messages in thread From: eggert at cs dot ucla.edu @ 2023-06-14 6:11 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094 Paul Eggert <eggert at cs dot ucla.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eggert at cs dot ucla.edu --- Comment #3 from Paul Eggert <eggert at cs dot ucla.edu> --- Slightly better is this equivalent: unsigned f (long a) { return __builtin_sub_overflow (0, a, &a); } which gcc -O2 (or -Os) compiles into: f: xor %eax, %eax neg %rdi seto %al ret which with GCC is one byte less machine code than the __builtin_sub_overflow(a, 1, &a) approach. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 [not found] <bug-90094-4@http.gcc.gnu.org/bugzilla/> 2021-07-25 1:06 ` [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 pinskia at gcc dot gnu.org 2023-06-14 6:11 ` eggert at cs dot ucla.edu @ 2023-06-14 8:58 ` jakub at gcc dot gnu.org 2023-06-14 9:00 ` jakub at gcc dot gnu.org 3 siblings, 0 replies; 4+ messages in thread From: jakub at gcc dot gnu.org @ 2023-06-14 8:58 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org, | |uros at gcc dot gnu.org --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- But then shouldn't we do it not just for equality/non-equality comparisons against 0x8000000000000000, but also for equality/non-equality comparisons against 0x7fffffffffffffff or signed non-equality comparisons like > __LONG_MAX__ - 42 or >= __LONG_MAX__ - 0x7fffff00 etc. I mean void fn (void); unsigned f1 (long a) { return a == -__LONG_MAX__ - 1; } void f2 (long a) { if (a == -__LONG_MAX__ - 1) fn (); } unsigned f3 (long a) { return __builtin_sub_overflow_p (0, a, 0L); } void f4 (long a) { if (__builtin_sub_overflow_p (0, a, 0L)) fn (); } unsigned f5 (long a) { return a == __LONG_MAX__; } void f6 (long a) { if (a == __LONG_MAX__) fn (); } unsigned f7 (long a) { return __builtin_add_overflow_p (a, 1, 0L); } void f8 (long a) { if (__builtin_add_overflow_p (a, 1, 0L)) fn (); } unsigned f9 (long a) { return a >= __LONG_MAX__ - 42; } void f10 (long a) { if (a >= __LONG_MAX__ - 42) fn (); } unsigned f11 (long a) { return __builtin_add_overflow_p (a, 43, 0L); } void f12 (long a) { if (__builtin_add_overflow_p (a, 43, 0L)) fn (); } unsigned f13 (long a) { return a <= -__LONG_MAX__ + 42; } void f14 (long a) { if (a <= -__LONG_MAX__ + 42) fn (); } unsigned f15 (long a) { return __builtin_sub_overflow_p (a, 43, 0L); } void f16 (long a) { if (__builtin_sub_overflow_p (a, 43, 0L)) fn (); } The question if it should be done in the cstoredi4 and cbranchdi4 expanders, or matched later say during combine, or peephole2. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 [not found] <bug-90094-4@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2023-06-14 8:58 ` jakub at gcc dot gnu.org @ 2023-06-14 9:00 ` jakub at gcc dot gnu.org 3 siblings, 0 replies; 4+ messages in thread From: jakub at gcc dot gnu.org @ 2023-06-14 9:00 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094 --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- One argument against doing it during expansion is that if we need the large constant for other purposes, loading it with movabsq and just doing comparison is better, the overflow way also clobbers the register which is being compared. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-06-14 9:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-90094-4@http.gcc.gnu.org/bugzilla/> 2021-07-25 1:06 ` [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64 pinskia at gcc dot gnu.org 2023-06-14 6:11 ` eggert at cs dot ucla.edu 2023-06-14 8:58 ` jakub at gcc dot gnu.org 2023-06-14 9:00 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).