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.to...@gmail.com> wrote: > On Mon, Aug 5, 2013 at 9:33 AM, Xinliang David Li <davi...@google.com> wrote: >> On Mon, Aug 5, 2013 at 8:26 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Sun, Aug 4, 2013 at 9:23 AM, Xinliang David Li <davi...@google.com> >>> wrote: >>>> On Sun, Aug 4, 2013 at 4:40 AM, Richard Biener >>>> <richard.guent...@gmail.com> wrote: >>>>> Xinliang David Li <davi...@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.
