This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: long long performance
- To: Rob Willis <rob at e-critical dot com>
- Subject: Re: long long performance
- From: Torbjorn Granlund <tege at swox dot com>
- Date: 14 Dec 2000 00:35:36 +0100
- Cc: gcc at gcc dot gnu dot org
- References: <3A37F1ED.ED6C4133@e-critical.com>
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