This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR 10011: Introduce gcse_constant_p
- From: Roger Sayle <roger at www dot eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 30 Mar 2003 16:21:33 -0700 (MST)
- Subject: Re: [PATCH] PR 10011: Introduce gcse_constant_p
On Sun, 30 Mar 2003, Richard Henderson wrote:
> On Sun, Mar 16, 2003 at 06:51:37PM -0700, Roger Sayle wrote:
> > PR middle-end/10011
> > * gcse.c (gcse_constant_p): New function to identify constants
> > suitable for constant propagation, including COMPARE with two
> > integer constant arguments.
> > (hash_scan_set): Use gcse_constant_p.
> > (find_avail_set): Likewise.
> > (cprop_insn): Likewise.
> > (do_local_cprop): Likewise.
> > (find_implicit_sets): Likewise.
> > (find_bypass_set): Likewise.
>
> This is ok, since it is a nice cleanup.
Ok, after giving more thought to your solution I'm not opposed
to the new location, provided the OK above counts as approval
for the gcse_constant_p fix. As long as the underlying problem
is also corrected, your move has the nice side-effect of simplifying
the logic.
> In particular, what happens in each case is that we purge the
> constant_p_rtx, replace it with a zero, and then loop optimization
> moves the assignment out of the loop before the branch is simplfied.
This is the comment that led me astray. It turns out that the only
thing run between the new location and the old location are CSE and
CFG clean-ups. So it isn't "loop" that's responsible for moving
the assignment to a different basic block, but CSE proving that an
earlier assignment of the condition codes are still live. Given
the plans to restrict CSE to basic blocks and for atleast some of the
four CSE passes to go away, I'm happy that your change is a step in
the right direction.
Sorry. That was an approval right?
Roger
--