www.digitalmars.com         C & C++   DMDScript  

D.gnu - bug report x86-64 code: je / jbe

reply Cecil Ward <cecil cecilward.com> writes:
I have just noticed a bug in the latest release of GDC that 
targets x86-64. For example GDC 12.3 and above versions too, 
running on X86-64, targeting self. This was built with:
  -O3 -frelease -march=alderlake

Generated code is:

    je L1
    jbe L1

     …
     …
L1:  ret

The probably reason for this is my use of the GDC built in for 
indicating whether conditional jumps are likely or unlikely to be 
taken. I wrote a trivial routine likely() and unlikely() and used 
this as follows:

public
T pow(T, exp_ui_t )( in T x, in exp_ui_t p ) pure  safe nothrow 
 nogc
     	if ( is ( exp_ui_t == ulong ) || is ( exp_ui_t == uint ) )
in	{
     static assert( is ( typeof( x * x ) ) );
     assert( p >= 0 );
     }
out ( ret ) {
     assert( ( p == 0 && ret == 1 ) || !( p == 0 ) );
     }
do
     {
     if ( unlikely( p == 0 ) ) return 1;
     if ( unlikely( p == 1 ) ) return x;

     /*
     if ( unlikely( x == 0 ) )	// fast-path opt, unnecessary
     	return x;
     if ( unlikely( x == 1 ) )	// fast-path opt, unnecessary
     	return x;
     */
   	
     T s = x;
     T v = 1;
   	
     for ( exp_ui_t i = p; i > 1; i >>= 1 )
	{
	v = ( i & 0x1 ) ? s * v : v;
	s = s * s;
	}
    //assert( p > 1 && pow( x, p ) == ( p > 1 ? x * pow( x, p-1) : 
1) );
     return v * s;
     }

pragma( inline, true )
private
bool builtin_expect()( in bool test_cond, in bool expected_cond ) 
  pure nothrow  safe  nogc
{
     version ( LDC )
     	{// ldc.intrinsics.llvm_expect - didi not seem to work when 
tested in LDC 1.22
     	import ldc.intrinsics : llvm_expect;
     	return cast(bool) llvm_expect( test_cond, expected_cond );
     	}
     version ( GDC )
     	{
     	import gcc.builtins : __builtin_expect;
     	return cast(bool) __builtin_expect( test_cond, expected_cond 
);
     	}
     return test_cond;
     }


pragma( inline, true )
public
bool likely()( in bool test_cond ) pure nothrow  safe  nogc
/* Returns test_cond which makes it convenient to do assert( 
unlikely() )
  * Also emulates builtin_expect's return behaviour, by returning 
the argument
  */	{
     return builtin_expect( test_cond, true );
     }


pragma( inline, true )
public
bool unlikely()( in bool test_cond ) pure nothrow  safe  nogc
/* Returns test_cond which makes it convenient to do assert( 
unlikely() )
  * Also emulates builtin_expect's return behaviour, by returning 
the argument
  */
     {
     return builtin_expect( test_cond, false );
     }
// ~~~ module likely - end.

====

This is not the whole of this .d file, I can of course give you 
the whole lot if you desire. I inspected the result in Matt 
Godbolt’s compiler explorer website godbolt.org.

An aside: LDC:: I need to look at LDC’s llvm_expect to see if it 
is controlling the branches the way I wish. Does anyone know if 
llvm_expect has any problems?
Jun 14 2023
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 14 June 2023 at 12:35:43 UTC, Cecil Ward wrote:
 I have just noticed a bug in the latest release of GDC that 
 targets x86-64. For example GDC 12.3 and above versions too, 
 running on X86-64, targeting self. This was built with:
  -O3 -frelease -march=alderlake
What leads you to believe that it is buggy?
 Generated code is:

    je L1
    jbe L1
What I see is the first instruction is going to relate to this condition.
     if ( unlikely( p == 1 ) ) return x;
Then the next instruction is the condition in the following for-loop.
     for ( exp_ui_t i = p; i > 1; i >>= 1 )
Redundant jump? Yes, arguably. Leads to wrong runtime? Doesn't look that way.
Jun 16 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Friday, 16 June 2023 at 13:12:06 UTC, Iain Buclaw wrote:
 On Wednesday, 14 June 2023 at 12:35:43 UTC, Cecil Ward wrote:
 I have just noticed a bug in the latest release of GDC that 
 targets x86-64. For example GDC 12.3 and above versions too, 
 running on X86-64, targeting self. This was built with:
  -O3 -frelease -march=alderlake
What leads you to believe that it is buggy?
 Generated code is:

    je L1
    jbe L1
What I see is the first instruction is going to relate to this condition.
     if ( unlikely( p == 1 ) ) return x;
Then the next instruction is the condition in the following for-loop.
     for ( exp_ui_t i = p; i > 1; i >>= 1 )
Redundant jump? Yes, arguably. Leads to wrong runtime? Doesn't look that way.
Completely agree with Iain, it’s not incorrect code, I wasn’t intending to suggest that. I’d just say suboptimal, and not the very best code generation possible.
Jun 17 2023
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Sunday, 18 June 2023 at 02:55:32 UTC, Cecil Ward wrote:
 On Friday, 16 June 2023 at 13:12:06 UTC, Iain Buclaw wrote:
 Redundant jump? Yes, arguably. Leads to wrong runtime? Doesn't 
 look that way.
Completely agree with Iain, it’s not incorrect code, I wasn’t intending to suggest that. I’d just say suboptimal, and not the very best code generation possible.
By the way, I suspect it's related to this problem report. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435 Taken from upstream DMD comment (I suspect is still not fixed in either DMD, possibly LDC too but haven't checked). https://issues.dlang.org/show_bug.cgi?id=20148#c3 Essentially, every read of a boolean gets turned into `(*(ubyte*)&b) & 1`. This *could* be limited to ` safe` code, or just accessing field members of a union I suppose.
Jun 19 2023
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 19 June 2023 at 09:54:32 UTC, Iain Buclaw wrote:
 On Sunday, 18 June 2023 at 02:55:32 UTC, Cecil Ward wrote:
 On Friday, 16 June 2023 at 13:12:06 UTC, Iain Buclaw wrote:
 Redundant jump? Yes, arguably. Leads to wrong runtime? 
 Doesn't look that way.
Completely agree with Iain, it’s not incorrect code, I wasn’t intending to suggest that. I’d just say suboptimal, and not the very best code generation possible.
By the way, I suspect it's related to this problem report. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435
Fix has been committed in time for 13.2 release.
Jun 25 2023