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/50751] SH Target: Displacement addressing does not work for QImode and HImode Date: Mon, 12 Dec 2011 02:29:00 -0000 [thread overview] Message-ID: <bug-50751-4-ONjemV5LBz@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 #20 from Oleg Endo <oleg.endo@t-online.de> 2011-12-12 02:11:12 UTC --- (In reply to comment #19) > 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. That looks nice! Thanks for checking it out! I haven't ran CSiBE with "-O2 -fpic", only with "-Os -mpretend-cmove -mfused-madd -freg-struct-return". I will use your params and try to see what is happening in those cases where it gets worse. Maybe it can be "fixed" with a peephole. > > > /* 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; > >+ Thus we allow the mode change for -O0. */ .. should be _disallow_ of course... Another note that should have went into the comment: As far as I could observe it, this is mainly triggered by the following in sh_legitimate_index_p: + if (mode == QImode && (unsigned) INTVAL (op) < 16) + return true; .. probably because this makes the generic "m" constraint match QImode displacement addressing and then it tries using it. > 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. Yeah, could also be an option. > It'll also help some unfortunate anormallies for which those optimizations > will generate worse codes. You mean, by giving the user the option to turn off displacement addressing for e.g. some specific files / modules by specifying -mno-preferdisp or something like that? By anomalies do you mean code that gets worse because of too much pressure on R0 and all the reloads around it, or do you have any other bad use cases? BTW, the vector mode handling seems a bit unfinished (see also PR13423). I was planning to address that at a later point... > 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. Yes, the "m" constraint is an obstacle in this case. What I've tried out is splitting it into a memory constraint that allows displacement addressing and another memory constraint that disallows it ("Snd", "Sdd" - they are added by the patch) and use those in the move / sign extend insns instead of the generic "m" constraint. For example something like that: (define_insn "*extendqisi2" [(set (match_operand:SI 0 "arith_reg_dest" "=z,r,r") (sign_extend:SI (match_operand:QI 1 "general_movsrc_operand" Sdd,Snd,r")))] "TARGET_SH1" "@ mov.b %1,%0 mov.b %1,%0 exts.b %1,%0" [(set_attr "type" "load,load,arith")]) This basically seems to work. But when there are consecutive loads, reload would use displacement addressing for the first load, but not for the following loads because R0 will be already allocated at that point. Ideally, reload should take into account that "reloading around R0" is in most cases more efficient than other strategies, especially on SH4. However, I'm not sure whether changing reload for this issue is a good idea ;) Another thing I could try out is to have load/store insns that allow arbitrary operands in displacement addressing like on SH2A, and split them into two insns of one load/store and one reg-reg move after reload. But that would probably require the R0 clobber in the expander which could make worse code in cases where displacement addressing is not used, I guess. Do you think this approach could make sense? > 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. I was afraid you might say something like this :T > You have the time for implementing HImode support. Yep, sure. I've noticed that the latest version of the patch seems to fix some more testsuite failures. I will investigate which hunk is responsible for the fixes so that could be pulled out from the patch. OK? > BTW, the changes for white spaces, spells and other clean-ups which > are not essential for this work should be separated into another patch. Ah yeah, sure. Will pull them out and submit as a cleanup patch to the patches-list.
next prev parent reply other threads:[~2011-12-12 2:11 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 2011-12-12 2:29 ` oleg.endo@t-online.de [this message] 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-ONjemV5LBz@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).