This is the mail archive of the
mailing list for the GCC project.
Re: [Patchv2 3/4] Control SRA and IPA-SRA by a param rather than MOVE_RATIO
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Andrew Pinski <pinskia at gmail dot com>
- Date: Wed, 29 Oct 2014 14:39:18 +0000
- Subject: Re: [Patchv2 3/4] Control SRA and IPA-SRA by a param rather than MOVE_RATIO
- Authentication-results: sourceware.org; auth=none
- References: <CAFiYyc33WnFRGZiSLz+b8dFX=eE_pkoHPoTMFEN3zna-rRUKTQ at mail dot gmail dot com> <1411657056-24865-1-git-send-email-james dot greenhalgh at arm dot com> <1411657056-24865-4-git-send-email-james dot greenhalgh at arm dot com> <CAFiYyc1DEHWVZt=mehT2KJB5OsOVW6Ew7QPXVnnN1LW_KeExuA at mail dot gmail dot com> <20141001163812 dot GA5945 at arm dot com>
On Wed, Oct 01, 2014 at 05:38:12PM +0100, James Greenhalgh wrote:
> On Fri, Sep 26, 2014 at 10:11:13AM +0100, Richard Biener wrote:
> > On Thu, Sep 25, 2014 at 4:57 PM, James Greenhalgh
> > <email@example.com> wrote:
> > Given the special value to note the default for the new --params is
> > zero a user cannot disable scalarization that way.
> > I still somehow dislike that you need a target hook to compute the
> > default. Why doesn't it work to do, in opts.c:default_options_optimization
> > maybe_set_param_value
> > (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
> > get_move_ratio (speed_p) * MOVE_MAX_PIECES,
> > opts->x_param_values, opts_set->x_param_values);
> > and override that default in targets option_override hook the same way?
> The problem I am having is getting "get_move_ratio" right, without breaking
> the modular design.
> default_options_optimization, and the rest of opts.c is going to end up in
> libcommon-target.a, so we are not going to have access to any
> backend-specific symbols.
> An early draft of this patch used the MOVE_RATIO macro to set the default
> value. This worked fine for AArch64 and ARM targets (which both use a
> simple C expression for MOVE_RATIO), but failed for x86_64 which defines
> MOVE_RATIO as so:
> #define MOVE_RATIO(speed) ((speed) ? ix86_cost->move_ratio : 3)
> Dealing with that ix86_cost symbol is what causes us the pain.
> It seems reasonable that a target might want to define MOVE_RATIO
> as some function of their tuning parameters, so I don't want to
> disallow that usage.
> This inspired me to try turning this in to a target hook, but this
> doesn't help as opts.c only gets access to common-target.def target
> hooks. These suffer the same problem, they don't have access to any
> backend symbols.
> I suppose I could port any target with a definition of MOVE_RATIO to
> override the default parameter value in their option overriding code,
> but that makes this a very large patch set (many targets define
> Is this an avenue worth exploring? I agree the very special target
> hook is not ideal.
Did you have any further thoughts on this? I'm still unable to come up
with a way to set these parameters which allows them to default to their
current (MOVE_RATIO derived) values.
If the only way to make this work is to add code to
TARGET_OPTION_OVERRIDE for all targets that define MOVE_RATIO, then I
suppose I can do that, but I'd prefer a neater way to make it work, if
you can think of one.