On 11/5/19 3:13 PM, Richard Biener wrote:
On Thu, Oct 31, 2019 at 2:17 PM Martin Liška <mli...@suse.cz> wrote:
On 10/31/19 2:16 PM, Martin Liška wrote:
On 10/31/19 2:01 PM, Martin Liška wrote:
Hi.
Based on the discussion with Honza and Richard I'm sending a proposal
for conversion of param machinery into the existing option machinery.
Our motivation for the change is to provide per function param values,
similarly what 'Optimization' keyword does for options.
Right now, we support the following format:
gcc --param=lto-partitions=4 /tmp/main.c -c
And so that I decided to name newly the params like:
-param=ipa-sra-ptr-growth-factor=
Common Joined UInteger Var(param_ipa_sra_ptr_growth_factor) Init(2) Param
Optimization
Maximum allowed growth of number and total size of new parameters
that ipa-sra replaces a pointer to an aggregate with.
And I learnt decoder to parse '--param' 'name=value' as '--param=name=value'.
Doing that
the transformation works. Help provides reasonable output as well:
$ ./xgcc -B. --param predictable-branch-outcome=5 /tmp/main.c -c -Q
--help=param
The --param option recognizes the following as parameters:
--param=ipa-sra-ptr-growth-factor= 2
--param=predictable-branch-outcome=<0,50> 5
Thoughts?
Thanks,
Martin
---
gcc/common.opt | 18 +++++++++++-------
gcc/ipa-sra.c | 3 +--
gcc/opt-functions.awk | 3 ++-
gcc/opts-common.c | 9 +++++++++
gcc/opts.c | 36 ------------------------------------
gcc/params.def | 10 ----------
gcc/predict.c | 4 ++--
7 files changed, 25 insertions(+), 58 deletions(-)
I forgot to add gcc-patches to To.
Martin
+ the patch.
Nice.
Thanks.
I wonder if we can auto-generate params.h so that
PARAM_VALUE (...) can continue to "work"? But maybe that's too much
and against making them first-class (but "unsupported") options. At least
it would make the final patch _much_ smaller... (one could think of
auto-generating an enum and using an array of params for the storage
again - but then possibly split for [non-]Optimization - ugh). If we
(auto-)name
the variables all-uppercase like PARAM_IPA_SRA_PTR_GROWTH_FACTOR
we could have
#define PARAM_VALUE (x) x
... (that said, everything that helps making the transition hit GCC 10
is appreciated ;))
Well, to be honest I would like to get rid of the current syntax:
PARAM_VALUE (PARAM_PREDICTABLE_BRANCH_OUTCOME) and replace it with something
what we have for normal options: param_predictable_branch_outcome.
It will require a quite big mechanical change in usage, but I can do
the replacement almost automatically.
For
+-param=ipa-sra-ptr-growth-factor=
+Common Joined UInteger Var(param_ipa_sra_ptr_growth_factor) Init(2)
Param Optimization
I wonder if both Var(...) and Param can be "autodetected" (aka
actually required)?
Right now, Var is probably not required. Param can be handled by putting all
the params into a new param.opt file.
At least the core of the patch looks nicely small! How do the OPT_ enum values
for a --param look like?
Yep, I also like how small it is.
OPT__param_ipa_sra_ptr_growth_factor_ = 62,/*
--param=ipa-sra-ptr-growth-factor= */
OPT__param_predictable_branch_outcome_ = 63,/*
--param=predictable-branch-outcome= */
Martin
Thanks,
Richard.
Martin
