On Fri, Apr 05, 2013 at 03:00:43PM -0600, Jeff Law wrote:
> On 04/05/2013 02:50 PM, Jakub Jelinek wrote:
> >On Fri, Apr 05, 2013 at 02:42:19PM -0600, Jeff Law wrote:
> >>? I must be missing something, the change causes an early bail out
> >>from try_crossjump_to_edge.
> >>
> >>We don't want to raise the min to > 0 as that doesn't allow the user
> >>to turn on this specific transformation.
> >
> >The condition is
> > if (nmatch < PARAM_VALUE (PARAM_MIN_CROSSJUMP_INSNS))
> > return false; // aka "don't crossjump"
> >So, the smaller the N in --param min-crossjump-insns=N is, the more likely
> >we crossjump. Thus N=0 should mean that it is most likely we crossjump,
> >and as N=1 requires that at least one insn matches, N=0 would mean that
> >even zero insns can match. If we for --param min-crossjump-insns=0
> >always return false, it means we never crossjump, so it is least likely
> >that we crossjump, which corresponds to largest possible N, not smallest
> >one.
> Yes the smaller the N, the more likely we are to crossjump, of
> course the value 0 would make no sense (I'm clearly out of practice
> on reviews :-).
>
> Yea, changing the min value in params.def to 1 would be a better way
> to fix. Consider that patch pre-approved.
Ok, thanks. I'll apply this one. Regtest/bootstrap pending.
2013-04-08 Marek Polacek <pola...@redhat.com>
PR rtl-optimization/48182
* params.def (PARAM_MIN_CROSSJUMP_INSNS): Increase the minimum
value to 1.
--- gcc/params.def.mp 2013-04-08 08:38:48.515263034 +0200
+++ gcc/params.def 2013-04-08 08:39:10.444340238 +0200
@@ -433,7 +433,7 @@ DEFPARAM(PARAM_MAX_CROSSJUMP_EDGES,
DEFPARAM(PARAM_MIN_CROSSJUMP_INSNS,
"min-crossjump-insns",
"The minimum number of matching instructions to consider for
crossjumping",
- 5, 0, 0)
+ 5, 1, 0)
/* The maximum number expansion factor when copying basic blocks. */
DEFPARAM(PARAM_MAX_GROW_COPY_BB_INSNS,
Marek
