This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] new post-reload compare elimination pass
- From: Jeff Law <law at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, ebotcazou at libertysurf dot fr
- Date: Mon, 29 Nov 2010 22:50:07 -0700
- Subject: Re: [RFC] new post-reload compare elimination pass
- References: <4CF4399B.firstname.lastname@example.org>
On 11/29/10 16:39, Richard Henderson wrote:
At first glance this reminded me a lot of the old comparison elimination
code in final, as it should since the code we want to generate is the
same -- the major difference is this code twiddles the RTL to match
reality where the old code waited until it was late enough on the
pipeline that it could just change the assembly code without downstream
Since NickC is away for the next month or so, I spent some of the
long weekend trying to help him out with the mn10300 comparison
problem for which he's already sent two revisions. The patch is
along the lines I proposed here:
This adds a new post-reload pass, which is only enabled by backends
that require it, e.g.
as will be seen in the mn10300 backend patch that uses this.
+ /* Enable comparison elimination, unless explicitly disabled. */
+ if (optimize&& !global_options_set.x_flag_compare_elim_after_reload)
+ flag_compare_elim_after_reload = 1;
I tried to use the df.h interfaces more, but I couldn't seem to find
any easy way to walk a def-def chain. I'd need that to easily notice
the LUID of the clobber of the flags register preceding a compare. In
the end it seemed easiest to simply walk the insn chain and keep track.
Comments wrt this specific patch?
With that in mind, I looked over the old code in final.c to see if there
were any high level gotchas -- the only ones that stuck out where checks
to ensure the comparison didn't have a volatile operand or an operand
with an auto-increment addressing mode. I don't see similar checks in
your new pass.
I don't think it's necessary right now, but handling conditional moves,
conditional traps & setcc insns might be useful one day as well.
Overall, the pass looks pretty simple. I presume you verified it
actually eliminated some comparisons on the mn103 port? Did NickC give
you a testcase or two to work with?