From: Richard Biener <rguenther@suse.de>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Tobias Burnus <burnus@net-b.de>,
gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
Subject: Re: New modref/ipa_modref optimization passes
Date: Fri, 16 Oct 2020 11:20:23 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2010161105580.10073@p653.nepu.fhfr.qr> (raw)
In-Reply-To: <nycvar.YFH.7.76.2010161004271.10073@p653.nepu.fhfr.qr>
On Fri, 16 Oct 2020, Richard Biener wrote:
> On Fri, 16 Oct 2020, Jan Hubicka wrote:
>
> > Hi,
> > I am slowly getting finished with the fn spec changes on trunk and then
> > would like to proceed with modref. Sadly still get the assumed_type
> > failuere and in addition to that:
> > FAIL: gfortran.dg/finalize_25.f90 -O2 execution test
> > FAIL: gfortran.dg/finalize_25.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> > FAIL: gfortran.dg/finalize_25.f90 -O3 -g execution test
> > FAIL: gfortran.dg/finalize_25.f90 -Os execution test
> > WARNING: gfortran.dg/pdt_14.f03 -O2 execution test program timed out.
> > FAIL: gfortran.dg/pdt_14.f03 -O2 execution test
> > WARNING: gfortran.dg/pdt_14.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> > program timed out.
> > FAIL: gfortran.dg/pdt_14.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> > WARNING: gfortran.dg/pdt_14.f03 -O3 -g execution test program timed out.
> > FAIL: gfortran.dg/pdt_14.f03 -O3 -g execution test
> > WARNING: gfortran.dg/pdt_14.f03 -Os execution test program timed out.
> > FAIL: gfortran.dg/pdt_14.f03 -Os execution test
> >
> > I wonder if there is any chance to get Fortran FE fixed here?
>
> OK, I'll try doing a little surgery in the FE today, coming up with
> a little refactoring and a fix along your original one that allows
> for a better one by FE folks.
So I've sent a refactoring patch improving the tree building code.
But now trying to fix the actual issue with the idea to perform
accesses indirectly via a descriptor with dim[] type I see that
the coarray 'token' field is appended to descriptors conditional
on -fcoarray and that this field makes the dim[] array no longer
trailing - which means the offset of the 'token' field depends
on the rank of the array.
The dim[] field is even optional when dim + codimen == 0 and that
case indeed happens (ah, via get_scalar_to_descriptor_type).
So much for re-using this combo ;)
I suppose we can compensate for this by dynamically computing the
offset of the 'token' field but then it's not obvious to me
where the total 'rank' is stored inside the descriptor or how
the 'token' field is accessed for assumed-shape arrays - the
current method by simple field chaining definitely won't work.
Anyway, I'll try to deal with all this by just adjusting the TBAA
type but not the access type leaving that alone.
IMHO the cleanest way would be to swap the CAF token field and
the dim[] field (which is an ABI change for -fcoarray)
Richard.
next prev parent reply other threads:[~2020-10-16 9:20 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-16 22:23 David Čepelík
2020-09-19 22:32 ` Jan Hubicka
2020-09-20 6:15 ` Jan Hubicka
2020-09-21 7:13 ` Richard Biener
2020-09-21 7:47 ` Jan Hubicka
2020-09-21 7:55 ` Richard Biener
2020-09-21 8:04 ` Jan Hubicka
2020-09-21 8:10 ` Richard Biener
2020-09-22 10:15 ` Tobias Burnus
2020-09-27 21:37 ` Jan Hubicka
2020-10-16 7:56 ` Jan Hubicka
2020-10-16 8:05 ` Richard Biener
2020-10-16 9:20 ` Richard Biener [this message]
2020-10-16 10:42 ` Richard Biener
2020-10-23 9:54 ` Bernhard Reutner-Fischer
2020-10-23 10:05 ` Andre Vehreschild
2020-10-29 15:14 ` Jan Hubicka
2020-10-30 8:16 ` Richard Biener
2020-09-20 14:33 ` David Malcolm
2020-09-20 17:30 ` Jan Hubicka
2020-09-20 23:27 ` David Malcolm
2020-09-22 18:47 ` Jan Hubicka
2020-09-22 20:19 ` Jan Hubicka
2020-09-21 23:14 ` David Malcolm
2020-09-22 6:45 ` Jan Hubicka
2020-09-22 7:07 ` Jan Hubicka
2020-09-22 11:21 ` David Malcolm
2020-09-22 12:29 ` Jan Hubicka
2020-09-22 18:39 ` Jan Hubicka
2020-09-22 20:13 ` David Malcolm
2020-09-22 20:21 ` David Malcolm
2020-09-22 20:24 ` Jan Hubicka
2020-09-22 20:47 ` Issue with ggc_delete and finalizers (was Re: New modref/ipa_modref optimization passes) David Malcolm
2020-09-23 8:31 ` Jan Hubicka
2020-09-24 6:30 ` Jan Hubicka
2020-09-25 14:42 ` David Malcolm
2020-09-22 20:23 ` New modref/ipa_modref optimization passes Jan Hubicka
2020-09-22 21:17 ` David Malcolm
2020-09-22 8:13 ` [committed] ipa: Fix up ipa modref option help texts Jakub Jelinek
2020-09-22 8:47 ` Jakub Jelinek
2020-09-22 9:12 ` Jan Hubicka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.YFH.7.76.2010161105580.10073@p653.nepu.fhfr.qr \
--to=rguenther@suse.de \
--cc=burnus@net-b.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).