[patch, fortran] Move some array packing to front end

[Chris Elrod]

Hi,
I just compiled gcc-trunk after applying your patches (p8.diff) and H.J.
Lu's patches from *Bug 88713*
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713> (vectorized code slow
vs Flang) fixing rsqrt.

Thomas Koenig already confirmed it fixed the problem I recorded there, but
figured I'd add that I can also confirm it improved the benchmarks
dramatically. gfortran and g++ now seem to be the fastest (one of the
Fortran benchmarks saw over 100x improvement). Between those two patches,
Bug 88713 will be solved.

LLVM also seems to have an issue where, if you don't store inside the
function being called within the loop, the loop body ends up with a lot of
leaq instructions. gcc now seems to produce the same code regardless
(without those unnecessary instructions). Obviously, just one simple narrow
example, but exciting to see that improvement!


On Thu, Jan 24, 2019 at 4:56 AM Richard Biener <richard.guenther@gmail.com>
wrote:

> On Wed, Jan 23, 2019 at 6:18 PM Thomas Koenig <tkoenig@netcologne.de>
> wrote:
> >
> > Hi Dominique,
> >
> > > FAIL: gfortran.dg/internal_pack_4.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
> > >
> > > with -m32.
> > >
> > > gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/internal_pack_4.f90 -O3
> -funroll-loops -ftracer -m32
> > >
> > > is enough to trigger the miscomputation.
> >
> > Thanks, I will look into it.
> >
> > > The changes in the test suite are quite messy and I hope I did not
> miss any test (you should do "diff -N …" for the new tests).
> >
> > I don't think this is a good idea.  Applying the patch twice will then
> > double the test case.
> >
> >
> > > Do you have test showing a speed-up?
> >
> > It' in the PR.
> >
> >
> > > I agree with Richard that this patch should be held until the next
> stage 1.
> >
> > I just realized that we are, in principle, in regression-only mode.
> >
> > I do wish the announcements were also made to the fortran mailing lists.
>
> They are made to the low-traffic gcc@ list which everybody working on GCC
> is supposed to subscribe to.
>
> > Anyway, I'll see if I can fix that bug, then attach the combined
> > patch to the PR for later inclusion.
> >
> > Regards
> >
> >         Thomas
>


-- 
https://github.com/chriselrod?tab=repositories
https://www.linkedin.com/in/chris-elrod-9720391a/