public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/47790] [4.5/4.6 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x
Date: Tue, 22 Feb 2011 17:38:00 -0000	[thread overview]
Message-ID: <bug-47790-4-YiNrsaffsE@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47790-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> 2011-02-22 17:09:36 UTC ---
A couple early comments.

First, it appears that it's never possible to get into this code via the old
path where SRC is a binary operation of some sort.  This is presumably an
artifact of how we handle expansion.

If I understand your change correctly, you're walking the use-def chain when
SRC is an SSA_NAME in the hopes of finding a suitable binary operation to set
SRC.  After that, you can just let the original code from
optimize_bitfield_assignment_op do its thing.

I found this fragment somewhat odd, what's its purpose?

+  if (TREE_CODE (op0) == SSA_NAME)
+    {
+      gimple op0stmt = get_gimple_for_ssa_name (op0);
+      if (!op0stmt || !is_gimple_assign (op0stmt) || gimple_assign_rhs_code
(op0stmt) != TREE_CODE (to) )
+    return false;
+      op0 = gimple_assign_rhs1 (op0stmt);
+    }


At this point OP0 is the RHS1 of the statement which set SRC via binary
operator.

Second, the original code stripped nops from OP0.  Is there some reason you
don't do that?  It probably doesn't matter, but you might be missing some
optimization opportunities as a result.

>From peeking at the testcase, if we could handle the case where SRC is a
typecast which is fed by a binary operation, we might have many more
opportunities to optimize.  I guess that should be considered extra credit.


  parent reply	other threads:[~2011-02-22 17:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18  0:08 [Bug middle-end/47790] New: " pinskia at gcc dot gnu.org
2011-02-18  0:13 ` [Bug middle-end/47790] " pinskia at gcc dot gnu.org
2011-02-18 20:57 ` pinskia at gcc dot gnu.org
2011-02-21 23:56 ` law at redhat dot com
2011-02-22 17:38 ` law at redhat dot com [this message]
2011-03-18 14:03 ` [Bug middle-end/47790] [4.5/4.6/4.7 " law at gcc dot gnu.org
2011-03-18 14:10 ` law at redhat dot com
2011-03-18 14:17 ` rguenth 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-47790-4-YiNrsaffsE@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).