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