public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction Date: Thu, 25 May 2023 21:32:35 +0000 [thread overview] Message-ID: <bug-49263-4-BUhFFNi8ED@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-49263-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #40 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Alexander Klepikov from comment #39) > > I'm sorry, but .md lang is too complicated for me. Yeah, it looks alien at first sight. But it's where a lot of things happen w.r.t. instruction selection. > It looks like with optimization enabled it converts bitwise AND to right > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be > optimized to 'tst'. And SH2E has libcall instead of dynamic shift and libcll > cannot be converted. It seems that very first optimization spoils things. > > But when we have numerous 'shar' instructions, optimization joins the game > again and converts them to 'tst'. Yes, something like this is what I remember happening there. I'll try to look into the issue with your test cases and see if it's possible to add some patterns to catch those. BTW, have you tried it on a more recent GCC? There have also been some optimizations in the middle-end (a bit more backend independent) for this kind of thing. > You are absolutely right, the code will be larger when we do right shifts. > But there's situations when you can't use library. For exmple, SH7055 engine > control unit can barely contain the program. The library just won't fit. Have you tried to use whole program optimization via -flto and -ffunction-sections? It should be able to strip out all unnecessary library functions.
next prev parent reply other threads:[~2023-05-25 21:32 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 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 [this message] 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-BUhFFNi8ED@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: linkBe 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).