This is the mail archive of the gcc-patches@gcc.gnu.org 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: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....


ok -- makes sense. This can be done as a follow up patch.

thanks,

David

On Mon, Aug 5, 2013 at 10:59 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Aug 5, 2013 at 9:33 AM, Xinliang David Li <davidxl@google.com> wrote:
>> On Mon, Aug 5, 2013 at 8:26 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Sun, Aug 4, 2013 at 9:23 AM, Xinliang David Li <davidxl@google.com> wrote:
>>>> On Sun, Aug 4, 2013 at 4:40 AM, Richard Biener
>>>> <richard.guenther@gmail.com> wrote:
>>>>> Xinliang David Li <davidxl@google.com> wrote:
>>>>>>Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
>>>>>>in ix86_tune_features[], indexed by ix86_tune_indices) to perform
>>>>>>micro-arch specific performance tuning. However such settings are hard
>>>>>>coded (fixed with a given -mtune setting) and is very hard to do
>>>>>>performance experiment.
>>>>>>
>>>>>>The attached patch fixes the problem. The patch introduces a new
>>>>>>option -mtune-ctrl=. Its parameter is a comma separated list of
>>>>>>feature names to turn on associated features. Feature name can be
>>>>>>prefixed by ^ to do the opposite. For instance,
>>>>>>
>>>>>>  -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns
>>>>>>
>>>>>>tells the compiler to use move instructions in prologue/epilogue
>>>>>>(instead of push/pop), and *not* pad return instructions.
>>>>>>
>>>>>>To facilitate the change, the feature tuning enums defined in i386.h
>>>>>>are moved to a new file x86-tune.def and this file can be used to
>>>>>>generate both the enums and names of the features.
>>>>>>
>>>>>>
>>>>>>Ok for trunk?
>>>>>>
>>>>>
>>>>> The patch fails to add documentation. And I am nervous about testing coverage - is this considered a development option only or are random combinations expected to work in all situations? I expect not, thus this looks like a dangerous option?
>>>>>
>>>>
>>>> This option is intended to be used by developers -- otherwise we will
>>>> have to document all possible feature knobs. I saw a couple of
>>>> existing options in i386.opt marked as 'Undocumented' -- is this mark
>>>> used for case like this?   Since this option is for experimental
>>>> purpose, user certainly can shoot their foot with it :)
>>>>
>>>> If there is support of target specific --params which takes strings as
>>>> args, it might be a better choice to use that.
>>>>
>>>
>>> I have a similar patch to turn on/off each feature and it is very
>>> useful to fine tune x86 backend.  But mine is not automated.
>>> Anothing I found useful is a command line switch to turn off all
>>> features, like -mno-default.
>>
>>
>> Turn off all features or just toggle the features? What is the use
>> case for -mno-default?
>>
>
> -mno-default tunes off all features.  To turn on only features: f1,
> f2, f3, --,fN.
> we can do
>
> -mno-default -mtune-ctrl=f1,f2,,..,fN
>
> We don't need to check if other features are off since they are
> turned off by -mno-default.
>
>
> --
> H.J.


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