public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "meissner at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/33699] [9/10/11/12 regression] missing optimization on const addr area store
Date: Thu, 08 Jul 2021 17:16:16 +0000	[thread overview]
Message-ID: <bug-33699-4-pGxq5Vpyji@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-33699-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu.org

--- Comment #32 from Michael Meissner <meissner at gcc dot gnu.org> ---
I looked at adding the following powerpc patch that was proposed in March,
2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566744.html

There are two parts to the patch, that are sort of unrelated.

The first part is to add minimum and maximum section anchor offset values and
use -fsection anchors.  I ran a spec 2017 benchmark on a pre-production power10
system, comparing my normal run times to run times with -fsection-anchors and
setting the minimum/maximum section anchor offsets.

Two benchmarks improved and two benchmarks regressed:

    xalancbmk_r: 1.75% regression
    cactuBSSN_r: 4.24% improvement
    blender_r: 1.92% regression
    roms_r: 1.05% improvement

I then built spec 2017 with just the part of setting const_anchor, but not the
section anchor minimum/maximum offsets.  Eight benchmarks did not build due to
assertion failures in cse.c:

    gcc_r
    exchange2_r
    cactuBSSN_r
    wrf_r
    blender_r
    cam4_r
    fotonik3d_r
    roms_r

If I specify the section anchor minimum/maximum offsets, add -fsection-anchors,
and set the const_anchor, all 23 INT+FP benchmarks build, but WRF_R does not
run correctly.  So without more debugging, I don't recommend setting
const_anchor.  It is probably useful to set the minimum/maximum section anchor
offsets in case people use -fsection-anchors.

As an aside, if we wanted to accept using constant addresses in the PowerPC, we
would need to recognize a constant address as being legitimate.  This may be
useful in some embedded environments where you have devices at certain memory
locations.  But somebody would need to add the support.

  parent reply	other threads:[~2021-07-08 17:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-33699-4@http.gcc.gnu.org/bugzilla/>
2011-03-04 12:13 ` [Bug middle-end/33699] [4.3/4.4/4.5/4.6 " rguenth at gcc dot gnu.org
2011-03-04 15:33 ` matz at gcc dot gnu.org
2011-06-27 14:58 ` [Bug middle-end/33699] [4.3/4.4/4.5/4.6/4.7 " rguenth at gcc dot gnu.org
2012-03-13 15:07 ` [Bug middle-end/33699] [4.5/4.6/4.7/4.8 " jakub at gcc dot gnu.org
2012-07-02 11:49 ` rguenth at gcc dot gnu.org
2012-12-31 10:09 ` [Bug middle-end/33699] [4.6/4.7/4.8 " pinskia at gcc dot gnu.org
2013-04-12 15:18 ` [Bug middle-end/33699] [4.7/4.8/4.9 " jakub at gcc dot gnu.org
2014-06-12 13:49 ` [Bug middle-end/33699] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
2014-12-19 13:43 ` [Bug middle-end/33699] [4.8/4.9/5 " jakub at gcc dot gnu.org
2015-06-23  8:26 ` [Bug middle-end/33699] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org
2015-06-26 20:17 ` [Bug middle-end/33699] [4.9/5/6 " jakub at gcc dot gnu.org
2015-06-26 20:38 ` jakub at gcc dot gnu.org
2021-05-14  9:45 ` [Bug middle-end/33699] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:04 ` rguenth at gcc dot gnu.org
2021-07-08 17:16 ` meissner at gcc dot gnu.org [this message]
2022-05-27  9:33 ` [Bug middle-end/33699] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:29 ` jakub at gcc dot gnu.org
2023-07-07 10:28 ` [Bug middle-end/33699] [11/12/13/14 " rguenth at gcc dot gnu.org

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=bug-33699-4-pGxq5Vpyji@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).