gsl @1.15_2: AVX should be disabled for variant +optimize

[daitakahashi]

Because an assembler provided by ccutils has not supported AVX instructions, all versions of gcc cannot compile a binary with AVX enabled. As a result, gsl cannot be build on Sandy-bridge or Ivy-bridge systems when the variant optimize and one of the gcc variants are enabled.

Here is a patch that disables AVX for variants +gcc44, +gcc45, gcc46 and gcc47. The AVX support was implemented from gcc 4.4 (​release note of gcc 4.4), so I suppose it does not affect gcc43 variant.

[daitakahashi]

Patch to add -mno-avx to cflags

[jochen@…]

Shouldn't the patch only disable AVX if that specific assembler is used? Generally it would be preferably to leave it in for performance reasons. How can we find out if it is used?

[daitakahashi]

I agree with your concerns about the performance impact, however, I think it is practically ignorable, because all assemblers included in ccutils are too old to support AVX instructions.

All the versions of macports' gcc use as from macports' ccutils and XCode's gcc uses /usr/bin/as, and both of those assemblers are too old. As a result, all of those gcc do not compile AVX (some people tried to replace an assembler by clang, but it looks just an experiment ​http://stackoverflow.com/questions/9840207/how-to-use-avx-pclmulqdq-on-mac-os-x-lion...).

[daitakahashi]

I misunderstood llvm-3.2. It supports autovectorization, and here is a preliminary patch on gsl/Portfile to compile it by clang-3.2. Although a libtool in the distribution needs to be patched to ignore -mllvm flags (​lists.gnu.org), build process succeeds without any errors, and resultant binaries include many AVX instructions.

However, those binaries fail some of the make check. Because a gsl with +gcc47 +optimize passes all those tests, it would be a problem of binaries built by llvm.

Here, I attach a new patch on gsl/Porifile, a patch on libtool, and output of make check.

[daitakahashi]

A Portfile patch to enable clang-3.2 build

[daitakahashi]

A patch on libtool to cope with an mllvm flag problem

[daitakahashi]

A logfile of make check (+clang32 +optimize)

[daitakahashi]

Because of the bugs in llvm's vectorizer, currently it is not good to rely on clang. And, using different assembler as a gcc's back end is not a standard setup. Therefore, I think disabling AVX is an only way to compile with optimized variant for most of users who need speed.

[NicosPavlov]

Cc Me!

[NicosPavlov]

I had a quick look at the patches. First, I would like to point out that I upgraded gsl to the version 1.16 in r109541 (before your mail on the mailing list), and I had missed this ticket, sorry for that.

When testing gsl 1.15 compiled with macport's gcc47, it indeed does not pass the tests in linalg, but when testing version 1.16, all tests passed without disabling AVX. With

export CFLAGS="-ftree-vectorize -O3 -march=native"

All tests are passed with version 1.16 with all gcc47, clang32 and the native clang on my system

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

Unless there is something I am missing, the upgrade to the latest version seems to have solved the compilation issues, so that additional flags or specific requirements for compilers may not be needed (to confirm perhaps depending on the OS version, but all bots compiled fine).

[daitakahashi]

Thank you very much for upgrading the port, and for looking my patches.

Here, the upgrade to 1.16 did not help. Still I cannot compile gsl with +gcc47 +optimize, due to the AVX instructions. Could you check your cpu architecture? The "-march=native" problem only appears when gsl is compiled on OSX machine with Sandybridge, Ivybridge, and Haswell cpu. Here is a list of machines with those cpus (from wikipedia).

• Macbook Pro: early 2011 or later
• Macbook Air: mid 2011 or later
• iMac: mid 2011 or later
• Mac mini: mid 2011 or later
• Mac Pro: currently none.

The option affects only on those machines, and harmless for others.

[petrrr]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[NicosPavlov]

Right, I missed this part and got tricked by the fact that gsl-1.15 was also failing the checks, even though my machine is Mid-2010.

Last check before committing, the latest Portfile diff sets gcc47 as the default compiler, and does not include the clang32 variant contained in the other files. This makes sense to me to not include the variants clang32, as there are apparently issues with clang, and that dealing with the default clang would be a priority over specific Macport versions anyway, but I just would like to confirm that this should be left out.

[daitakahashi]

The llvm <= 3.2 has a vectorizer bug, which potentially breaks all functions that uses datatype based on long long double, e.g., gsl_block_long_double (only AVX capable machines would be affected, otherwise the compiler may think the transform is costly, see ​http://llvm.org/bugs/show_bug.cgi?id=15758).

The fix is included in llvm-3.3 but not backported to the earlier versions, and also I had experienced inconsistent result from developmental version of llvm-3.3 that caused by, maybe, another bug.

So, I decided that still it is better to wait for the maturation of llvm, and I removed a variant for compiling llvm-3.2 (but it is still possible by using the apple's default compiler).

And could you please remove the default variant from the patch? Hopefully, the llvm-3.2 does not vectorize the code by default, and I misunderstand the combination effect of variant conflict and default variant. I updated the patch.

[daitakahashi]

disable AVX to enable optimized build on newer machines

[NicosPavlov]

Alright, makes sense. Committed in r109811.

Then, if the clang compilers causing problems become clearer, it should be possible to forbid them with the compiler.blacklist command.