public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kugan at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65768] sub-optimimal code for constant Uses in loop Date: Wed, 15 Apr 2015 07:12:00 -0000 [thread overview] Message-ID: <bug-65768-4-BA9I3uzN4w@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-65768-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65768 kugan at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |kugan at gcc dot gnu.org --- Comment #1 from kugan at gcc dot gnu.org --- Zhenqiang posted following patches in this regard. [PATCH, cprop] Check rtx_cost when propagating constant https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html [PATCH, ARM] Keep constants in register when expanding https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00325.html Note that, Zhenqiang's patch still will not work for 0x00ff00ff and works only for 0xfe00ff (as used in the testcase for the above patch). For the case of 0x00ff00ff, this constant is splt by the backend during expand as: (insn 52 51 53 (set (reg:SI 154) (const_int 255 [0xff])) const1.c:6 -1 (nil)) (insn 53 52 54 (set (zero_extract:SI (reg:SI 154) (const_int 16 [0x10]) (const_int 16 [0x10])) (const_int 255 [0xff])) const1.c:6 -1 (nil)) The ZERO_EXTRACT has 255 as the src (from 0xff00ff) which (same constant 255) is also set in the same register in the previous instruction. So, during CSE, it detects that they are same and using r154 when simplifying ZERO_EXTRACT with the constant. But in the case of, 0xfe00ff, theses two constants are different (255 and 254) hence CSE simplifies it back to 0xfe00ff. RTL loop invariant code motion can now move it out. However, if the constant is still split and are constructed with two instructions, it will not be able to move it out. I believe the fix is to delay splitting. i.e., do not split for SET as well during expand. CSE simplifying ZERO_EXTRACT is probably not wise as well because it is doing this without consulting the back-end cost.
next prev parent reply other threads:[~2015-04-15 7:12 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-15 7:09 [Bug target/65768] New: " kugan at gcc dot gnu.org 2015-04-15 7:12 ` kugan at gcc dot gnu.org [this message] 2015-05-16 9:36 ` [Bug target/65768] " kugan at gcc dot gnu.org 2015-06-02 22:53 ` kugan at gcc dot gnu.org 2015-06-02 23:53 ` kugan 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-65768-4-BA9I3uzN4w@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).