On Fri, Sep 26, 2014 at 10:11:13AM +0100, Richard Biener wrote: > On Thu, Sep 25, 2014 at 4:57 PM, James Greenhalgh > <james.greenha...@arm.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 MOVE_RATIO). Is this an avenue worth exploring? I agree the very special target hook is not ideal. Thanks, James
