public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "oleg.endo@t-online.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
Date: Sun, 09 Oct 2011 23:35:00 -0000	[thread overview]
Message-ID: <bug-49263-4-EF14zxTTCd@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-49263-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263

--- Comment #7 from Oleg Endo <oleg.endo@t-online.de> 2011-10-09 23:34:45 UTC ---
(In reply to comment #6)

> Yep, maintenance burden but I don't mean ack/nak for anything.
> If it's enough fruitful, we should take that route.  When it
> gives 5% improvement in the usual working set like as CSiBE,
> hundreds lines would be OK, but if it's ~0.5% or less, it doesn't
> look worth to add many patterns for that.
> 
> > Isn't there a way to tell the combine pass not to do so, but instead first look
> > deeper at what is in the MD?
> 
> I don't know how to do it cleanly.
> 

I've tried out a couple of things and got some CSiBE numbers based on 
trunk rev 179430. Unfortunately only code size comparisons, no run time 
performance numbers. The tests were compiled with 
-ml -m4-single -Os -mnomacsave -mpretend-cmove -mfused-madd -freg-struct-return

Option 1)
  Use many (~10) patterns in the MD and some cost calculation tuning.
  The last patch required some adaptation, because the combine pass 
  started trying to match things slightly differently. I've also 
  noticed that it requires a special case for one pattern on SH4A...

  size of all modules: 2916390 -> 2909026    -7364 / -0.252504 %
  avg difference over all modules: -409.111111 / -0.273887 %
  max: compiler       22808 -> 22812           +4 / +0.017538 %
  min: libpng-1.2.5   99120 -> 97804        -1316 / -1.327684 %

Option 2)
  I've added another combine pass which has the make_compound_operation
  function turned off. The make_compound_operation function is used to
  produce zero_extract patterns. If the resulting "simplified" pattern does
  not match anything in the MD, combine reverts the transformation and 
  proceeds with the next insn. That way, it never tries to match the 
  tst #imm pattern in the MD. 
  With this option only ~5 patterns seem to be required and a small
  extension of the costs calculation.

  size of all modules:  2916390 -> 2909170    -7220 / -0.247566 %
  avg difference over all modules: -401.111111 / -0.254423 %
  max: compiler       22808 -> 22812           +4 / +0.017538 %
  min: libpng-1.2.5   99120 -> 97836        -1284 / -1.295400 %

Not so spectacular on average. It highly depends on the type of SW being
compiled, but it hits quite a lot of files in CSiBE.

Option 2 seems more robust even if it seems less effective, what do you think?


  parent reply	other threads:[~2011-10-09 23:35 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-01 20:17 [Bug target/49263] New: " oleg.endo@t-online.de
2011-06-01 20:42 ` [Bug target/49263] " oleg.endo@t-online.de
2011-06-12 23:12 ` kkojima at gcc dot gnu.org
2011-06-19 16:42 ` oleg.endo@t-online.de
2011-06-22 22:34 ` kkojima at gcc dot gnu.org
2011-06-26 22:31 ` oleg.endo@t-online.de
2011-06-27  5:15 ` kkojima at gcc dot gnu.org
2011-10-09 23:35 ` oleg.endo@t-online.de [this message]
2011-10-10  1:32 ` kkojima at gcc dot gnu.org
2011-10-10 23:48 ` oleg.endo@t-online.de
2011-10-11  1:47 ` kkojima at gcc dot gnu.org
2011-10-13 22:55 ` oleg.endo@t-online.de
2011-10-14 23:06 ` kkojima at gcc dot gnu.org
2011-10-15  2:33 ` kkojima at gcc dot gnu.org
2011-11-20 14:20 ` oleg.endo@t-online.de
2011-12-29  1:09 ` oleg.endo@t-online.de
2012-02-26 16:28 ` olegendo at gcc dot gnu.org
2012-02-26 23:29 ` olegendo at gcc dot gnu.org
2012-08-27 19:52 ` olegendo at gcc dot gnu.org
2012-10-28 22:02 ` olegendo at gcc dot gnu.org
2012-10-31 13:47 ` olegendo at gcc dot gnu.org
2013-12-08 13:47 ` olegendo at gcc dot gnu.org
2013-12-17 12:37 ` olegendo at gcc dot gnu.org
2014-12-30 18:45 ` olegendo at gcc dot gnu.org
2015-01-24 13:05 ` olegendo at gcc dot gnu.org
2015-01-26 23:57 ` olegendo at gcc dot gnu.org
2023-05-12 11:46 ` klepikov.alex+bugs at gmail dot com
2023-05-23 12:34 ` klepikov.alex+bugs at gmail dot com
2023-05-23 12:35 ` klepikov.alex+bugs at gmail dot com
2023-05-23 19:05 ` olegendo at gcc dot gnu.org
2023-05-24 11:40 ` klepikov.alex+bugs at gmail dot com
2023-05-24 11:57 ` olegendo at gcc dot gnu.org
2023-05-24 13:34 ` klepikov.alex+bugs at gmail dot com
2023-05-24 15:00 ` olegendo at gcc dot gnu.org
2023-05-25 17:53 ` klepikov.alex+bugs at gmail dot com
2023-05-25 21:32 ` olegendo at gcc dot gnu.org
2023-05-26 12:03 ` klepikov.alex+bugs at gmail dot com
2023-05-26 17:44 ` olegendo at gcc dot gnu.org
2023-05-28 10:24 ` klepikov.alex+bugs at gmail dot com
2023-05-28 10:48 ` olegendo at gcc dot gnu.org
2023-05-29 14:54 ` klepikov.alex+bugs at gmail dot com
2023-05-30  1:48 ` egallager at gcc dot gnu.org
2023-05-30  1:56 ` olegendo at gcc dot gnu.org
2023-05-30 12:42 ` klepikov.alex+bugs at gmail dot com
2023-05-30 19:57 ` olegendo at gcc dot gnu.org
2023-05-30 20:00 ` olegendo 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-49263-4-EF14zxTTCd@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).