public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "wilson at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
Date: Wed, 21 Oct 2020 05:58:40 +0000	[thread overview]
Message-ID: <bug-97417-4-yUfwvSMzAZ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97417-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #3 from Jim Wilson <wilson at gcc dot gnu.org> ---
The basic idea here is that the movqi pattern in riscv.md currently emits RTL
for a load that looks like this
  (set (reg:QI target) (mem:QI (address)))
As an experiment, we want to try changing that to something like this
  (set (reg:DI temp) (zero_extend:DI (mem:DI (address))))
  (set (reg:QI target) (subreg:QI (reg:DI temp) 0))
The hope is that the optimizer will combine the subreg with following
operations resulting in smaller faster code at the end.  And this should also
solve the volatile load optimization problem.  So we need a patch, and then we
need experiments to see if the patch actually produces better code on real
programs.  It should be fairly easy to write the patch even if you don't have
any gcc experience.  The testing part of this is probably more work than the
patch writing.

The movqi pattern calls riscv_legitmize_move in riscv.c, so that would have to
be modified to look for qimode loads from memory, allocate a temporary
register, do a zero_extending load into the temp reg, and then a subreg copy
into the target register.

You will probably also need to handle cases where both the target and source
are memory locations, in which case this already gets split into two
instructions, a load followed by a store.

You can look at the movqi pattern in arm.md file to see an example of how to do
this, where it calls gen_zero_extendqisi2.  Though for RISC-V, we would want
gen_zero_extendqidi2 for rv64 and gen_zero_extendqisi2 for rv32.

If the movqi change works, then we would want similar changes for movhi and
maybe also movsi for rv64.

It might also be worth checking whether zero-extend or sign-extend is the
better choice.  We zero extend char by default, so that should be best.  For
rv64, the hardware sign extends simode to dimode by default, so sign-extend is
probably best for that.  For himode I'm not sure, I think we prefer sign-extend
by default, but that isn't necessarily the best choice for loads.  This would
have to be tested.

You can see rtl dumps by using -fdump-rtl-all.  The combiner is the pass that
should be optimizing away the unnecessary zero-extend.  You can see details of
what the combiner pass is doing by using -fdump-rtl-combine-all.

  parent reply	other threads:[~2020-10-21  5:58 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-14 11:56 [Bug other/97417] New: " kjetilos at gmail dot com
2020-10-15 20:34 ` [Bug other/97417] " wilson at gcc dot gnu.org
2020-10-21  3:36 ` jiawei at iscas dot ac.cn
2020-10-21  5:58 ` wilson at gcc dot gnu.org [this message]
2020-10-27 11:18 ` jiawei at iscas dot ac.cn
2020-10-27 15:25 ` wilson at gcc dot gnu.org
2020-10-29  5:27 ` admin at levyhsu dot com
2020-10-29 22:49 ` wilson at gcc dot gnu.org
2020-10-30  8:35 ` admin at levyhsu dot com
2020-10-30 12:46 ` admin at levyhsu dot com
2020-11-04  6:10 ` admin at levyhsu dot com
2020-11-04  6:35 ` kito at gcc dot gnu.org
2020-11-04  7:03 ` admin at levyhsu dot com
2020-11-05 22:57 ` wilson at gcc dot gnu.org
2020-11-06  1:20 ` wilson at gcc dot gnu.org
2020-11-06  2:40 ` wilson at gcc dot gnu.org
2020-11-06  2:44 ` kito at gcc dot gnu.org
2020-11-06  3:35 ` wilson at gcc dot gnu.org
2020-11-06  9:46 ` admin at levyhsu dot com
2020-11-06 11:38 ` admin at levyhsu dot com
2020-11-06 20:44 ` wilson at gcc dot gnu.org
2020-11-06 21:08 ` wilson at gcc dot gnu.org
2020-11-09  8:35 ` admin at levyhsu dot com
2020-11-09  9:22 ` admin at levyhsu dot com
2020-11-10  5:20 ` admin at levyhsu dot com
2020-11-10  5:29 ` kito at gcc dot gnu.org
2020-11-10  5:34 ` admin at levyhsu dot com
2020-11-10  5:36 ` admin at levyhsu dot com
2020-11-10  6:01 ` admin at levyhsu dot com
2020-11-10 10:47 ` admin at levyhsu dot com
2020-11-11  1:21 ` wilson at gcc dot gnu.org
2020-11-11  5:43 ` admin at levyhsu dot com
2020-11-11  6:43 ` admin at levyhsu dot com
2020-11-11 19:35 ` wilson at gcc dot gnu.org
2020-11-12  1:26 ` admin at levyhsu dot com
2020-11-13  0:00 ` wilson at gcc dot gnu.org
2020-11-16  1:17 ` admin at levyhsu dot com
2020-11-16  3:24 ` kito at gcc dot gnu.org
2020-11-17 10:19 ` admin at levyhsu dot com
2020-11-18  6:09 ` admin at levyhsu dot com
2020-11-18 18:31 ` [Bug target/97417] " wilson at gcc dot gnu.org
2020-11-20  2:41 ` admin at levyhsu dot com
2020-11-20  3:32 ` wilson at gcc dot gnu.org
2020-11-23  6:17 ` admin at levyhsu dot com
2020-11-23  6:38 ` admin at levyhsu dot com
2020-11-23  7:43 ` admin at levyhsu dot com
2020-12-01  3:03 ` admin at levyhsu dot com
2020-12-08  9:22 ` admin at levyhsu dot com
2020-12-14 10:43 ` admin at levyhsu dot com
2020-12-15  9:55 ` admin at levyhsu dot com
2020-12-16  2:40 ` wilson at gcc dot gnu.org
2020-12-16  2:42 ` wilson at gcc dot gnu.org
2020-12-17 18:13 ` wilson at gcc dot gnu.org
2020-12-17 18:26 ` jiawei at iscas dot ac.cn
2020-12-21 15:08 ` jiawei at iscas dot ac.cn
2020-12-21 15:38 ` kito at gcc dot gnu.org
2020-12-21 16:09 ` jiawei at iscas dot ac.cn
2020-12-22  6:35 ` admin at levyhsu dot com
2020-12-25  3:31 ` kito at gcc dot gnu.org
2020-12-25  9:09 ` jiawei at iscas dot ac.cn
2021-02-13 20:24 ` cvs-commit at gcc dot gnu.org
2021-02-13 20:37 ` cvs-commit at gcc dot gnu.org
2021-02-13 20:48 ` wilson 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-97417-4-yUfwvSMzAZ@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).