--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-06 10:07 ---
Note that this shouldn't really be affected by strict aliasing or not. Note
that the FE generated IL causes the first alias pass to emit too conservative
alias info as well:
# VUSE MPT.5965_208230
D.6049_4652
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-06 10:24 ---
So, to sum up, the situation could be significantly improved by improving
the FE. (Like I noticed for I/O statements, where I provided a patch -
that was not accepted - to share temporary variables created for
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-06 10:34 ---
Basically, not re-using array descriptor variables is as bad as not re-using
I/O descriptor variables. I also wonder what this _gfortran_internal_{un,}pack
is about?
For
taux=gn(p2+p4)
gfortran generates
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-06 10:38
---
This one:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01762.html
basically it mentiones async I/O as a reason to not do it, but instead the
callee can copy the I/O structure in that case instead (it probably
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-06 10:50
---
So, currently you can build up arbitrary large chains of virtual clobbers with
write (*,*) 'hello'
write (*,*) 'hello'
...
as each of those writes create two un-partitionable SFTs. For arrays
temporaries
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-06 11:09
---
Actually it isn't that bad for I/O as long as there are no pointers to the
dt_parm structs in the IL (function arguments are ok).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-06 11:13
---
For array temporaries the pinning of SFTs happens because we have the address
of
the actual array _data_ in the IL:
# SFT.10_52 = VDEF SFT.10_51(D)
atmp.0.data = A.1;
the array descriptor itself is not the
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-01-06 11:46
---
As of optimization, the conversion sequence
atmp.0.data = A.1;
D.540_5 = atmp.0.data;
D.541_6 = (real(kind=4)[0:] *) D.540_5;
...
(*D.541_6)[S.5_1] = D.545_14;
can be optimized to
A.1[S.5_1] =
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-06 12:07
---
Note that the large FRE compile-time is a dup of PR34450, try experimenting
with --param sccvn-max-scc-size=N and find a N where the problem vanishes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 ---
I've done some experimenting with older GCC versions I have floating around on
my machines:
Compiling the test case with both 4.1.2 and 4.2.1 gives an ICE, so I guess we
can't exactly call this a regression.
But then
--- Comment #17 from rguenther at suse dot de 2008-01-06 22:12 ---
Subject: Re: Fortran FE generated IL pessimizes middle-end
IL and analysis
On Sun, 6 Jan 2008, jaydub66 at gmail dot com wrote:
--- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 ---
I've done
11 matches
Mail list logo
