This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Ping: [PATCH]Remove duplicate check on BRANCH_COST in fold-const.c
- From: "Bin Cheng" <bin dot cheng at arm dot com>
- To: "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>, "Andrew Pinski" <pinskia at gmail dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 13 Aug 2012 18:00:41 +0800
- Subject: Ping: [PATCH]Remove duplicate check on BRANCH_COST in fold-const.c
- References: <50111a4e.c1d3440a.06c3.ffffd750SMTPIN_ADDED@mx.google.com> <CA+=Sn1mJBS4as8zqqo+uKSFVYH-P6vYK2e+BiOJ1NTm2v3TFiw@mail.gmail.com> <501143BD.6070508@arm.com>
Ping.
> -----Original Message-----
> From: Richard Earnshaw
> Sent: Thursday, July 26, 2012 9:19 PM
> To: Andrew Pinski
> Cc: Bin Cheng; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH]Remove duplicate check on BRANCH_COST in fold-const.c
>
> On 26/07/12 11:27, Andrew Pinski wrote:
> > On Thu, Jul 26, 2012 at 3:20 AM, Bin Cheng <bin.cheng@arm.com> wrote:
> >> Hi,
> >> This patch removes the duplicate check on BRANCH_COST in
fold_truth_andor.
> >> The BRANCH_COST condition removed is a duplicate of the default
> >> definition of LOGICAL_OP_NON_SHORT_CIRCUIT.
> >> All current targets (mips and rs6000) that provide non-default
> >> definitions of LOGICAL_OP_SHORT_CIRCUIT set it to 0, so this patch is
> >> therefore just a code cleanup and does not change behaviour in the
compiler.
> >>
> >> I built mipsel-elf cross compiler and compared newlib/libstdc++
> >> compiled by the patched/original compilers.
> >>
> >> Is it OK?
> >
> > Just some history here on this. The BRANCH COST check was there
> > before LOGICAL_OP_NON_SHORT_CIRCUIT was added. I will be submitting a
> > patch which changes the MIPS definition soon but it will not be based
> > on the branch cost but rather than another option. So in the end it
> > might not be redundant as it is currently.
> >
> > Thanks,
> > Andrew
> >
>
> You can always factor BRANCH_COST into LOGICAL_OP_NON_SHORT_CIRCUIT (as
the
> default currently does), so there's no loss of functionality from removing
> this currently redundant check. However, the current definition is broken
in
> that it makes it impossible to force the compiler to use this optimization
> when the branch cost is low.
>
Is it OK?
Thanks