[arm64] Negative immediates

[Torbjörn Granlund]

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

  #define count_leading_zeros(count, x) \
    do { \
      UWtype __count; \
      __asm__ ("clz\t%0, %1" : "=r" (__count) : "r" (x)); \
      (count) = __count; \
    } while (0)
  
Seems about right.

(For some reason we use the more concrete U?DItype and U?SItype types in
much of the assembly code.  I don't know why we don't use the more
abstract UWtype.

We might want to clean that up at some points (but then probably after I
have had time to restore the currently 620 unavailable test configs).

  (aarch64 is likely not the only implementation with this issue)
  
I suppose the more mature platforms will have such issues bashed out.

  Note that count_leading_zeros_gcc_clz seems to work just fine, we
  could use that instead.
  
Have you tried both gcc and clang for correctness and code quality?  If
there is no regression, count_leading_zeros_gcc_clz is preferred as it
exposes the algebra and scheduling information to the compiler.

(The devsystem leg behind shell now has both gcc and clang installed.)

  Should we cast in the callers?
  umul_ppmm (digit, frac, frac, (mp_limb_t)10)
  
  Or in many umul_ppmm implementations? Probably the first solution I
  guess...
  
I prefer to put it in the implementations.  They should all have that
already as needed, except arm64.

  On aarch64, with "r"(var), gcc and clang always name the register x0
  (never w0), whether var is an int or a long long. On amd64, I get %al
  / %ax / %eax / %rax depending on the type of var.

You're right!  That seem quite odd, I'd say wrong, and is why things
happens to work with gcc.

(One can override it with 'w' after the % in the register constraint.
See aarch64_print_operand in gcc-4.8.2/gcc/config/aarch64/aarch64.c.)

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