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: Backend specific params.def? (Was Re: New parameters to control stringop expansion libcall strategy)

On Sat, Aug 3, 2013 at 1:06 AM, Jan Hubicka <> wrote:
>> On x86_64, when the expected size of memcpy/memset is known (e.g, with
>> FDO), libcall strategy is used with the size is > 8192. This value is
>> hard coded, which makes it hard to do performance tuning. This patch
>> adds two new parameters to do that. Potential usage includes
>> per-application libcall strategy min-size tuning based on summary data
>> with FDO (e.g, instruction workset size).
>> Bootstrap and tested on x86_64/linux. Ok for trunk?
>> thanks,
>> David
>> 2013-08-02  Xinliang David Li  <>
>>         * params.def: New parameters.
>>         * config/i386/i386.c (ix86_option_override_internal):
>>         Override default libcall size limit with parameters.
> Hi,
> problem with this is that we introduce generic --param that is used only
> by x86 backend.  I am not really guru on the command line options, but I think
> this is first time we try to do such thing.  I wonder if
> 1) We want to introduce target specific params.def

We do have target specific tuning code for parameters though  --
backend overrides the default value -- I think this is essentially
target specific params.

> 2) We want to use usual -msomething= options
> 3) We want to go this way?

I don't have strong opinion either way. To avoid controversy, let me
work on a -mxxx= version of the patch -- and hopefully it will be more



> Honza

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