This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ifcvt conditional execution and rtx_cost
- From: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org, Eric Christopher <echristo at redhat dot com>, Uros Bizjak <uros at kss-loka dot si>
- Date: Wed, 07 Jul 2004 15:32:29 +0100
- Subject: Re: ifcvt conditional execution and rtx_cost
- Organization: GNU
- References: <Pine.LNX.4.44.0407070634170.17653-100000@www.eyesopen.com>
On Wed, 2004-07-07 at 14:08, Roger Sayle wrote:
> On Tue, 6 Jul 2004, David Edelsohn wrote:
> > With all of your recent rtx_cost changes and your patch for
> > ifcvt.c, I would like to get your opinion on the appended ifcvt.c patch.
>
> Interesting! The problem is that half of the tests updated by your
> patch really need to be testing the instruction count and comparing
> that against MAX_CONDITIONAL_EXECUTE and the other half need to be
> summing the the rtx_costs and comparing that against BRANCH_COST.
> Neither the current code that always tests instruction counts, nor
> your patch that only compares rtx_costs is ideal, as these two different
> types of tests really require checking different metrics. But I agree
> some of the aspects of your patch are needed in ifcvt.c, and can be
> used to address Uros' PR rtl-optimization/15187. There's also another
> bug in this code...
What we really need, especially for the if-else conversion, is to
measure the cost of conditionally NOT executing an insn (assuming the
cost of conditionally executing an insn is the same as unconditionally
doing so).
On older ARM chips the non-execute cost was always 1 (so the number of
insns worked well as the metric). On some more recent chips it can be
more complex than that, sometimes the cost can be as high as executing
the insn.
R.