A little warning in GMP.h

Brian Gladman brg at gladman.plus.com
Sat Sep 25 09:17:34 CEST 2004


Torbjorn Granlund wrote:

> Brian Gladman <brg at gladman.plus.com> writes:
> 
>    >     return (__gmp_n != 0)?__gmp_l:0;
>   
>   
>   which produces:
>   
>   mov         edx,dword ptr [__gmp_n]
>   mov         ecx,dword ptr [__gmp_l]
>   neg         edx
>   sbb         edx,edx
>   and         edx,ecx
>   
>   with Microsoft VC++ (optimiser on, fast code), whereas:
>   
>    >>>      return __gmp_l & (-(signed)(mp_limb_t) (__gmp_n != 0));
>   
> [This is an edited version of the original GMP code.  The edits
> have made it incorrect.]
>   
>   produces:
>   
>   mov         ecx,dword ptr [__gmp_n]
>   xor         edx,edx
>   test        ecx,ecx
>   mov         ecx,dword ptr [__gmp_l]
>   setne       dl
>   neg         edx
>   and         edx,ecx
>   
> Another reason to avoid the Microsoft compiler; its optimizer
> cannot canonicalize equivalent trivial branch-free expressions.
> It is as if it statically generates fixed code from known idioms,
> but doesn't really perform algebraic equivalence tranformations.

And a good reason to use it is that it can, and very often does, produce 
the fastest code from the obvious ways of doing things without forcing 
the programmer to use obscure tricks to coax it into doing so.

I was simply hinting that, in all probability, the current GCC, Intel 
and Microsoft compilers (and others?) on the x86 can all produce 
branchless code from the obvious way of doing this task.

Designing GMP to work well with poor compilers at the expense of good 
ones is fine if you really think that this makes sense. But in my view 
this is a design philosophy that is from a bygone age.

And, of course, you can always trust someone on this list to turn a 
serious point into a cheap jibe at the Microsoft compiler.

    Brian Gladman



More information about the gmp-discuss mailing list