This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 100% speed improvement 3.4 -> 3.5 for ia64!! (?)
On Wed, 14 Apr 2004, Kaveh R. Ghazi wrote:
> > From: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>
> >
> > i.e. __divdf3 seems to be inlined in 3.5 but not in 3.4. Does this
> > also inhibit constant folding or builtin optimizations of
> > divisions? Or does __divdf3 enter the stages only just before
> > assembling? Inlining these does not cause any increase in stripped
> > binary size, 3.4 is 4433152 bytes and 3.5 4341032 bytes.
>
> Maybe one (or all) of these would help 3.4:
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02545.html
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00419.html
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00779.html
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00945.html
>
> Try 3.5 with combinations of -fno-inline-float-divide
> -fno-inline-int-divide and -fno-inline-sqrt and see what effect it
> has on your times.
-fno-inline-int-divide and -fno-inline-sqrt doesn't seem to exist, but
there are -mno-inline-float-divide -mno-inline-int-divide and
-mno-inline-sqrt. Now with -fno-inline-float-divide
-mno-inline-float-divide -mno-inline-int-divide -mno-inline-sqrt
I get very poor performance (45.6s/it(!) compared to the 8s/it for
3.4).
Using -minline-float-divide-min-latency -minline-int-divide-min-latency
doesn't change performance at all. Either all these options are not
working as expected, or there are more differences between 3.4 and 3.5 in
this area.
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/