Should we remove -DNO_ASM from GMP/MPFR for native builds?

[mikrosk]

Makefile.def / Makefile.in explicitly disable compiling in any assembly notifications:

m68k-atari-mint-gcc/Makefile.def

Lines 51 to 65 in 7720579

	host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
	// Work around in-tree gmp configure bug with missing flex.
	extra_configure_flags='--disable-shared LEX="touch lex.yy.c" @host_libs_picflag@';
	extra_make_flags='AM_CFLAGS="-DNO_ASM"';
	no_install= true;
	// none-*-* disables asm optimizations, bootstrap-testing
	// the compiler more thoroughly.
	host="none-${host_vendor}-${host_os}";
	// gmp's configure will complain if given anything
	// different from host for target.
	target="none-${host_vendor}-${host_os}"; };
	host_modules= { module= mpfr; lib_path=src/.libs; bootstrap=true;
	extra_configure_flags='--disable-shared @extra_mpfr_configure_flags@ @host_libs_picflag@';
	extra_make_flags='AM_CFLAGS="-DNO_ASM"';
	no_install= true; };

Both mpfr and gmp have a few bits of m68k asm code available (gmp even specifically for 020+ CPUs).

I'm torn on this one. On one hand, native m68k executables can use every spare CPU cycle available, on othe ther hand there may be a risk that something goes wrong as those are disabled by default and therefore not that much tested.

Also, there's a bit of work required as our config.sub handling doesn't differentiate between 68000, 68020+ and m5475 CPUs (it's always just "m68k").

There is even a bug in gcc7: passing "none-atari-mint" from gcc to gmp (gcc's way to tell gmp to disable CPU optimisations) doesn't work as expected (it is still evaluated as "m68k-atari-mint"), therefore the CPU is detected as "m68k" and therefore it adds -m68000 to the command line even when compiling ColdFire, silently producing a wrong library. Fortunately our official gcc-7.5.0 release (and executables) doesn't suffer from it, I had --disable-assembly patched in explicitly.

[th-otto]

Those flags are only used when you have explicitly setup to compile in-tree versions of gmp & mpfr.. Did you do that in your scripts?

Also, the libraries compiled this way are only used by the compiler, they are not installed, so it doesn't matter much whether they use assembly versions or not.

Generally, it would be simpler just to use precompiled versions, that would also avoid quirks like compiling the coldfire version with wrong flags.

[mikrosk]

Did you do that in your scripts?

Indeed. ./contrib/download_prerequisites is my favourite way of installing gmp/mpfr/mpc.

they are not installed, so it doesn't matter much whether they use assembly versions or not.

Well, they are linked to the final gcc executable, which hopefully results in a faster compilation or whatever they are used for.

avoid quirks like compiling the coldfire version with wrong flags

True but then you depend on the flags used by the packager.

[th-otto]

whatever they are used for.

If i'm not wrong they are mainly used to convert floating point constants.

True but then you depend on the flags used by the packager.

Why? If you don't use intree versions of them, it will just use already installed versions. If that would not work, it would also use wrong versions of mintlib and fdlibm.

[mikrosk]

If that would not work, it would also use wrong versions of mintlib and fdlibm.

But that's not the question here. The question is usage of optimised libgmp/libmpfr. So when the packager decides to ship them without the asm optimisations, you can't do anything about it. In-tree gmp/mpfr is more flexible in this matter.

[th-otto]

Yes, ok. Given that i was recently wrong with my assumption that --enable-checking does not make much difference, i guess the only way to tell whether a gmp library with/without NO_ASM makes a difference, is to build both versions, then doing some runtime tests.