[arm64] Negative immediates and lack of default Neon support

[Torbjörn Granlund]

Marc Glisse <marc.glisse at inria.fr> writes:

  On Wed, 24 Sep 2014, Torbjörn Granlund wrote:
  
  > There seem to be another problem with using clang for arm64, see the
  > build failures at <https://gmplib.org/devel/tm-date.html>.
  
  A piece of information I usually have a hard time finding is the
  compiler version, I don't think it gets printed at any time during the
  build. It might be hard, with all compilers having different syntax
  for that...

yourmachine$ ssh shell.gmplib.org
shell$ ssh leg
leg$ clang -v
Debian clang version 3.4.2-8 (tags/RELEASE_34/dot2-final) (based on LLVM 3.4.2)

> Apparently, clang disables Neon instruction assembly by default.  I
  > found that passing -mfpu=neon to the compiler helps.
  
  Ah, I didn't have that problem on debian. The defaults are apparently
  not the same :-(
  
My install is based on Debian.  (Install 14 of
https://gmplib.org/~tege/qemu.html)

  > This command line option is not recognised by gcc.  We therefore need to
  > split out clang handling in configure.ac.
  >
  > A related problem is whether Neon is actually optional for armv8.  My
  > understanding is that it is not optional, but I am not sure about that.
  > If it is optional, then we need to move Neon assembly code into a
  > arm64/neon subdirectory, and adjust configure.ac accordingly.
  
  I though neon was compulsory on ARMv8-A but some googling shows
  conversations where the words 'disable' and 'flexibility' appear a
  lot.
  Still, not enabling FP and neon by default seems like a questionable
  choice to me.

We at least need to pass -mfpu=neon to clang since it is sometimes
required and else presumably harmless.  We can defer any neon code
splitting until we know that's needed.

-- 
Torbjörn
Please encrypt, key id 0xC8601622