[Bug target/103090] [i386] GCC should use the SF and ZF flags in some atomic_fetch_op sequences

[pskocik at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090

Petr Skocik  changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #3 from Petr Skocik  ---
Tangentially related: Gcc and clang both kinda do badly with inline assembly
equivalents of these (locked or unlocked) too.
If you "output" a particular flag and test that, the codegen is great but if
you try to say "flags are set according to the result" (rather a common thing
in x86(-64)) with something like

asm("lock incl %0" : "+m"(*X), "=@ccz"(zf), "=@ccs"(sf));
if ( zf!=(*X==0) ){ __builtin_unreachable(); }
if ( sf!=(*X<0) ){ __builtin_unreachable(); }

and then immediately afterwards try to do with-0 comparisons against *X, then a
reload and a test/0-compare will be generated even though a smarter compiler
could just pick up on the flag assertions and avoid the reload and
test/0-compare: https://godbolt.org/z/7e8PKhTjY

[Bug target/103090] [i386] GCC should use the SF and ZF flags in some atomic_fetch_op sequences

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090

--- Comment #2 from Hongtao.liu  ---
Similar like Jakub did in r7-532, We need another IFN & optab to do the
optimization. The IFN and optab is like atomic_logic_test_and_set_sf which used
to perform logic operation and set SF.

[Bug target/103090] [i386] GCC should use the SF and ZF flags in some atomic_fetch_op sequences

[thiago at kde dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090

--- Comment #1 from Thiago Macieira  ---
One more:

bool tsign3(std::atomic &i)
{
// any two or more bits, so long as the sign bit is one of them 
// (or the compiler doesn't know what's in the variable)
int bits = 1 | signbit; 
return i.fetch_and(bits, std::memory_order_relaxed) & signbit;
}