On 06/09/13 08:57, Stefan Monnier wrote:
>> > If it's unacceptable to maintain both a macro and a function
>> > implementation for a few primitives, we can simply have the
>> > latter invoke the former -- that way, there's only one actual
>> > implementation.
> I could live with that.

OK, attached is a patch to do that.  I think this is a bit better than
a macro-only implementation as it makes the way forward clearer for
a few years from now, when we can assume GCC 4.8 or later.

This fixes the -O0 performance problem, so developers using pre-4.8
GCC (or clang) won't suffer.  Here are the measurements, where "old
patch" refers to the previous version of the patch with the XINT
etc. macros removed, and "new patch" refers to the attached.  The
benchmark is the same as before.  As before, the low-order digits
probably aren't that significant.

Fedora 17 x86-64, AMD Phenom II X4 910e
Clang 3.0 (Fedora 17)
GCC 4.8.1 (I built it)
single-process make (no -j)

		    (benchmark  make \    rm fns.o;   rm *.o;    make \
		       100000)   xdisp.o  make emacs  make emacs  bootstrap
GCC   -O2 unpatched    1.57       11.3        9.6       110          843
GCC   -O2 old patch    1.57       11.1        9.9       119	     847
GCC   -O2 new patch    1.38	  10.9	      9.9	118	     850
GCC   -Og unpatched    1.15        5.9        9.2        80          860
GCC   -Og old patch    1.15        6.4        9.5        87          879
GCC   -Og new patch    1.15	   6.4	      9.5	 86	     874
GCC   -O0 unpatched    2.89        3.1       12.4        57         1099
GCC   -O0 old patch   21.66        3.0       20.0        63         2442
GCC   -O0 new patch    2.89	   2.9	     13.2	 56	    1265
Clang -O2 unpatched    1.57	   6.3	      8.3	 65	     818
Clang -O2 old patch    1.34	   6.8	      8.5	 70	     826
Clang -O2 new patch    1.34	   6.8	      8.5	 70	     830
Clang -O0 unpatched    3.72        1.5       10.9	 34	    1159
Clang -O0 old patch   17.89	   1.4	     17.0	 39	    2309
Clang -O0 new patch    3.92	   1.4	     11.8	 34	    1332