This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR24518 and PR24520 - Improvements to MOD and
- From: Tim Prince <tprince at myrealbox dot com>
- To: Paul Thomas <paulthomas2 at wanadoo dot fr>
- Cc: tprince at computer dot org, jblomqvi at cc dot hut dot fi, tobias dot schlueter at physik dot uni-muenchen dot de, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Mon, 14 Nov 2005 08:11:44 -0800
- Subject: Re: [Patch, fortran] PR24518 and PR24520 - Improvements to MOD and
- References: <1131915389.c7dca09ctprince@myrealbox.com> <43781E7A.1000905@wanadoo.fr>
- Reply-to: tprince at computer dot org
Paul Thomas wrote:
Tim,
Itanium linux results showed no significant difference between
in-lined and library results, except for a large gain at all loop
lengths for in-lining the sparse dot product.
Is that for real(8) or real(16)? Can you explain the lack of a difference?
Paul
This was for default real, using options -O3 -funroll-loops
-frename-registers. I should have tried -ffast-math in the hope of
eliminating SIR stalls. Default real actually has more potential
performance problems than double precision on Itanium, some of which gcc
has no way to recognize.
I wasn't aware of a gfortran real(16) implementation for Itanium.
Supporting that correctly in ia64.md would be a great deal of work. I
have looked extensively at ia64.md in the past, and there was support
for real(10) but not real(16).
I'll try to look into the performance question. If -frename-registers
is not having the intended effect, that would explain ineffectiveness of
other optimizations.
Sorry for the delay, I'm working from a hotel and from SC05, and just
now got my emailer configuration reconciled.