This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR48182
- From: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 05 Apr 2013 15:00:43 -0600
- Subject: Re: [PATCH] Fix PR48182
- References: <20130405152230 dot GH24873 at redhat dot com> <515F3265 dot 7090804 at redhat dot com> <20130405203309 dot GJ20334 at tucnak dot redhat dot com> <515F372B dot 5010604 at redhat dot com> <20130405205005 dot GK20334 at tucnak dot redhat dot com>
On 04/05/2013 02:50 PM, Jakub Jelinek wrote:
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 :-).
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
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
Yea, changing the min value in params.def to 1 would be a better way to
fix. Consider that patch pre-approved.