public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode Date: Mon, 12 Dec 2011 02:11:00 -0000 [thread overview] Message-ID: <bug-50751-4-JhCsijlFRs@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-50751-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #19 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-12-11 23:57:13 UTC --- (In reply to comment #18) The results look way better now. I've tested your latest patch for sh4-unknown-linux-gnu and found no new regressions for gcc testsuite. CSiBE with "-O2 -fpic" on that target shows that 144 improvements and 28 dis-improvements for size on 896 files. The worst case is -4.34783 net/ipv4/ip_forward 704 736 which looks the case of the high r0 register pressure. The best one is 25.7426 arch/testplatform/kernel/traps 10160 8080 which looks to be very impressive. > /* We want to enable the use of SUBREGs as a means to > VEC_SELECT a single element of a vector. */ >+ >+ /* This effectively disallows using GENERAL_REGS for SFmode vector subregs. >+ This can be problematic when SFmode vector subregs need to be accessed >+ on the stack with displacement addressing, as it happens with -O0. >+ Thus we allow the mode change for -O0. */ > if (to == SFmode && VECTOR_MODE_P (from) && GET_MODE_INNER (from) == SFmode) >- return (reg_classes_intersect_p (GENERAL_REGS, rclass)); >+ return optimize ? (reg_classes_intersect_p (GENERAL_REGS, rclass)) : false; Rather than that, I guess that the QI/HImode disp addressing would be an optimization unneeded for -O0 in the first place. Perhaps something like -mpreferdisp option and TARGET_PREFER_DISP macro which are enable by default but disable at -O0 might be help. It'll also help some unfortunate anormallies for which those optimizations will generate worse codes. > There are probably smarter ways of doing what the patch does. I have also > tried out implementing it with predicates and constraints, few load/store insns > and lots of alternatives in the insns. However, reload would refuse to select > the displacement addressing due to pressure on R0 in many cases. Maybe. Implementing it with predicates and constraints would be smarter if possible but may be difficult because the register allocator handles the "m" constraint specially. > Would something like the attached patch be acceptable (after some cleanups)? > If so, I'd also start adding HImode displacement addressing support. I think so, though we are in stage 3 and have to wait the trunk returns to stage 1 or 2 for committing such changes. You have the time for implementing HImode support. BTW, the changes for white spaces, spells and other clean-ups which are not essential for this work should be separated into another patch.
next prev parent reply other threads:[~2011-12-11 23:58 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-10-16 22:56 [Bug target/50751] New: " oleg.endo@t-online.de 2011-10-17 0:30 ` [Bug target/50751] " kkojima at gcc dot gnu.org 2011-10-17 0:38 ` oleg.endo@t-online.de 2011-10-17 0:51 ` kkojima at gcc dot gnu.org 2011-10-23 21:57 ` oleg.endo@t-online.de 2011-10-24 23:05 ` kkojima at gcc dot gnu.org 2011-10-26 22:37 ` oleg.endo@t-online.de 2011-10-26 23:07 ` oleg.endo@t-online.de 2011-10-27 2:31 ` kkojima at gcc dot gnu.org 2011-10-27 9:31 ` oleg.endo@t-online.de 2011-10-27 21:11 ` oleg.endo@t-online.de 2011-10-27 21:54 ` oleg.endo@t-online.de 2011-10-27 22:35 ` kkojima at gcc dot gnu.org 2011-11-02 0:16 ` oleg.endo@t-online.de 2011-11-02 0:58 ` kkojima at gcc dot gnu.org 2011-11-02 1:38 ` oleg.endo@t-online.de 2011-11-18 0:03 ` oleg.endo@t-online.de 2011-11-28 13:18 ` oleg.endo@t-online.de 2011-12-11 1:00 ` oleg.endo@t-online.de 2011-12-12 2:11 ` kkojima at gcc dot gnu.org [this message] 2011-12-12 2:29 ` oleg.endo@t-online.de 2011-12-12 22:16 ` kkojima at gcc dot gnu.org 2012-02-26 23:24 ` olegendo at gcc dot gnu.org 2012-03-19 19:19 ` olegendo at gcc dot gnu.org 2012-03-21 20:39 ` olegendo at gcc dot gnu.org 2012-03-27 20:37 ` olegendo at gcc dot gnu.org 2012-04-05 18:44 ` olegendo at gcc dot gnu.org 2012-04-11 11:35 ` olegendo at gcc dot gnu.org 2012-04-11 23:01 ` olegendo at gcc dot gnu.org 2012-04-19 9:31 ` olegendo at gcc dot gnu.org 2012-04-30 19:38 ` olegendo at gcc dot gnu.org 2012-08-09 15:51 ` olegendo at gcc dot gnu.org 2012-08-14 17:54 ` olegendo at gcc dot gnu.org 2013-11-26 11:48 ` olegendo at gcc dot gnu.org 2013-12-06 19:34 ` olegendo at gcc dot gnu.org 2013-12-08 14:19 ` olegendo at gcc dot gnu.org 2014-09-12 17:29 ` olegendo at gcc dot gnu.org 2014-12-07 22:57 ` olegendo at gcc dot gnu.org 2014-12-07 22:59 ` olegendo at gcc dot gnu.org 2014-12-07 23:01 ` olegendo at gcc dot gnu.org 2015-02-08 22:26 ` 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-50751-4-JhCsijlFRs@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).