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.
