public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Jan Hubicka <hubicka@kam.mff.cuni.cz>,
	"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
Cc: "Martin Liška" <mliska@suse.cz>,
	"Richard Sandiford" <richard.sandiford@arm.com>,
	"GCC Patches" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] vect: Remove vec_outside/inside_cost fields
Date: Thu, 11 Nov 2021 11:09:08 +0100	[thread overview]
Message-ID: <CAFiYyc09SpPGw0ZH4e=x5GPQUA-GPA5Qz5F7wkYP=hos_m7T5Q@mail.gmail.com> (raw)
In-Reply-To: <20211111094451.GI97553@kam.mff.cuni.cz>

On Thu, Nov 11, 2021 at 10:45 AM Jan Hubicka via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> > > >
> > > > I think the patch causes the following on x86_64-linux-gnu:
> > > > FAIL: gfortran.dg/inline_matmul_17.f90   -O   scan-tree-dump-times optimized "matmul_r4" 2
> > >
> > > I get that failure even with d70ef65692f (from before the patches
> > > I committed today).
> >
> > Sorry, you are right, it's one revision before:
> > d70ef65692fced7ab72e0aceeff7407e5a34d96d
> >
> > Honza, can you please take a look?
> The test looks for matmul_r4 calls which we now optimize out in fre1.
> This is because alias info is better now
>
>   afunc (&__var_5_mma);
>   _188 = __var_5_mma.dim[0].ubound;
>   _189 = __var_5_mma.dim[0].lbound;
>   _190 = _188 - _189;
>   _191 = _190 + 1;
>   _192 = MAX_EXPR <_191, 0>;
>   _193 = (real(kind=4)) _192;
>   _194 = __var_5_mma.dim[1].ubound;
>   _195 = __var_5_mma.dim[1].lbound;
>   _196 = _194 - _195;
>   _197 = _196 + 1;
>   _198 = MAX_EXPR <_197, 0>;
>   _199 = (real(kind=4)) _198;
>   _200 = _193 * _199;
>   _201 = _200 * 3.0e+0;
>   if (_201 <= 1.0e+9)
>     goto <bb 76>; [INV]
>   else
>     goto <bb 87>; [INV]
>   <bb 76> :
>   c = {};
>
>
>   afunc (&__var_5_mma);
>   c = {};
>
> Now afunc writes to __var_5_mma only indirectly so I think it is correct that
> we optimize the conditional out.
>
> Easy fix would be to add -fno-ipa-modref, but perhaps someone with
> better understanding of Fortran would help me to improve the testcase so
> the calls to matmul_r4 remains reachable?

I think the two matmul_r4 cases were missed optimizations before so just
changing the expected number of calls to zero is the correct fix here.  Indeed
we can now statically determine the matrices are not large and so only
keep the inline copy.

Richard.

>
> Honza

  reply	other threads:[~2021-11-11 10:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08 10:43 Richard Sandiford
2021-11-08 10:51 ` Richard Biener
2021-11-10 16:47 ` Martin Liška
2021-11-10 17:18   ` Richard Sandiford
2021-11-11  8:45     ` Martin Liška
2021-11-11  9:44       ` Jan Hubicka
2021-11-11 10:09         ` Richard Biener [this message]
2021-11-11 17:54           ` 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='CAFiYyc09SpPGw0ZH4e=x5GPQUA-GPA5Qz5F7wkYP=hos_m7T5Q@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@kam.mff.cuni.cz \
    --cc=mliska@suse.cz \
    --cc=richard.sandiford@arm.com \
    /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).