This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patchv2 3/4] Control SRA and IPA-SRA by a param rather than MOVE_RATIO

On Fri, Sep 26, 2014 at 10:11:13AM +0100, Richard Biener wrote:
> On Thu, Sep 25, 2014 at 4:57 PM, James Greenhalgh
> <> 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
>    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

  #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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]