long long performance

[Torbjorn Granlund]

Rob Willis <rob@e-critical.com> writes:

  Thanks for the info.  Assuming the longlong multiply isn't too much more
  complex, it still does not explain the 13x slower performance over that
  of just a normal long mulitply.  The timing on my P3/600 gave the
  following (i've already subtracted out the overhead for the loop and
  variable assignment):
  
  All times are for 1 billion operations to complete.
  
  long long mult:  33 secs
  long mult:       2.4 secs
  
  Which just seems wrong.

If you're using gcc 2.95.2, the 32x32->64 multiply pattern in i386.md
is disabled by default.  Therefore, you will get a function call to
_muldi3 for the former case.

If a 32x32->64 instruction is available to the compiler, it will form
64x64->64 multiply with one 32x32->64, and two 32x32->32 multiplies,
plus two plain additions.  Very simple.

The situation in the current sources is not better.  Somebody disabled
code generation of the critical patterns alltogether.  That will hurt
64-bit arithmetic and division-by-constants.

I think the * should go away from

 (define_insn "*umulsi3_highpart"
  ... )

and

 (define_insn "*smulsi3_highpart"
  ... )

so that the code generator can use these!

-- 
Torbjörn