Re: [PATCH] Prototype of hook for possible list of option values.
On 07/23/2018 03:47 PM, Richard Earnshaw (lists) wrote: > On 20/07/18 12:06, Martin Liška wrote: >> On 07/20/2018 12:58 PM, Richard Earnshaw (lists) wrote: >>> Modifiers are context dependent. The architecture implies which >>> modifiers can be applied (and what they mean in detail, so, for example, >>> +fp means enable the default floating point variant for this >>> architecture). Not all modifiers apply to all architectures - +fp is >>> not permitted on ARMv4t, for example. >> >> I see, that said I would really add just the target hook suggested. It will >> help people in bash completions and provide reasonable list in --help output. >> >> More complex approaches are possible, but don't worth in my opinion. >> If you agree, I can clean up the API and improve documentatio? >> >> Martin >> > > I do wonder if it would be helpful for the API to be able to provide a > 'prefix value' for prematching. So that, for example, > > -mcpu=cortex > > would pass 'cortex' as a pre-match and then the compiler could supply > just the valid cpus that start with cortex. or > > -mcpu=cortex-a5+ > > would pass 'cortex-a5+' and the compiler can supply the valid extensions > to that CPU. Can be definitely beneficial for bash completion. I'll clean up tomorrow the API and then you can implement the target hook. I'm going to do implementation for i386. It's simpler, there is only a list of possible values. Thanks, Martin > > R. >
Re: [PATCH] Prototype of hook for possible list of option values.
On 20/07/18 12:06, Martin Liška wrote: > On 07/20/2018 12:58 PM, Richard Earnshaw (lists) wrote: >> Modifiers are context dependent. The architecture implies which >> modifiers can be applied (and what they mean in detail, so, for example, >> +fp means enable the default floating point variant for this >> architecture). Not all modifiers apply to all architectures - +fp is >> not permitted on ARMv4t, for example. > > I see, that said I would really add just the target hook suggested. It will > help people in bash completions and provide reasonable list in --help output. > > More complex approaches are possible, but don't worth in my opinion. > If you agree, I can clean up the API and improve documentatio? > > Martin > I do wonder if it would be helpful for the API to be able to provide a 'prefix value' for prematching. So that, for example, -mcpu=cortex would pass 'cortex' as a pre-match and then the compiler could supply just the valid cpus that start with cortex. or -mcpu=cortex-a5+ would pass 'cortex-a5+' and the compiler can supply the valid extensions to that CPU. R.
Re: [PATCH] Prototype of hook for possible list of option values.
On 07/20/2018 12:58 PM, Richard Earnshaw (lists) wrote: > Modifiers are context dependent. The architecture implies which > modifiers can be applied (and what they mean in detail, so, for example, > +fp means enable the default floating point variant for this > architecture). Not all modifiers apply to all architectures - +fp is > not permitted on ARMv4t, for example. I see, that said I would really add just the target hook suggested. It will help people in bash completions and provide reasonable list in --help output. More complex approaches are possible, but don't worth in my opinion. If you agree, I can clean up the API and improve documentatio? Martin
Re: [PATCH] Prototype of hook for possible list of option values.
On 20/07/18 11:54, Martin Liška wrote:
> On 07/20/2018 12:25 PM, Richard Earnshaw (lists) wrote:
>> On 20/07/18 11:14, Martin Liška wrote:
>>> On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote:
On 20/07/18 09:04, Martin Liška wrote:
> Hi.
>
> I'm sending patch candidate with suggested target common hook. It allows
> a target
> to list all possible values for an option. Using the API, I implemented
> -march and
> -mtune option listing on i386.
>
> Richard you asked about the values. Yes, target should list all possible
> values,
> mainly because --help=target output needs all of these.
>
> Thoughts?
> Martin
>
I don't think anyone can reasonably write an implementation of this hook
based on this specification:
+@deftypefn {Common Target Hook} {vec}
TARGET_GET_VALID_OPTION_VALUES (int)
+The hook is used for options that have a non-trivial list of possible
option values.
+@end deftypefn
+
What's the int parameter for? What's the lifetime of the result (who
cleans it up)? If I need to allocation memory strings in the vector,
where do I do that? Can I assume GC memory in the driver, for example?
>>>
>>> Sure, can be improved, please take it as prototype.
>>>
Frankly though, I don't really want to enumerate every possible
permutation of the options for the architecture like this, though. It's
just too brute force and the answer is likely to be hundreds (haven't
>>>
>>> That's why I recommended you to list in --help=target content of
>>> arm_arch enum. You replied that it's not complete list of all possible
>>> values.
>>> Note that we are talking about content of --help option, it's not a
>>> documentation,
>>> it should just help users. Similar to bash completion, it should not be
>>> 100% perfect.
>>>
sat down to count it). What's more, the extensions might have meaning
in the order in which they appear. So, for example,
-march=armv8-a+crypto+nosimd
would be very different from
-march=armv8-a+nosimd+crypto
since the extensions are applied from left to right (the first collapses
to armv8-a+nosimd, the latter to armv8-a+crypto, but there are more
complex cases as well which I don't want to dig into here).
It would be a practical impossibility to list all of these.
>>>
>>> Yes, that's why I recommended to list only base march values. Modifiers can
>>> be mentioned
>>> aside if desired.
>>
>> So it might be feasible to print something like:
>>
>> arch1[+ext1|+ext2]*
>> arch2[+ext1|+ext3|...]*
>
> This is not feasible for --completion= option (bash completion).
>
> Just for sure, are we talking only about aarch64 feature modifiers. Or do you
> have any other
> special suffixes used in -march, -mtune, -mcpu option values?
>
> What about listing all possible modifiers after possible values for -march?
>
Modifiers are context dependent. The architecture implies which
modifiers can be applied (and what they mean in detail, so, for example,
+fp means enable the default floating point variant for this
architecture). Not all modifiers apply to all architectures - +fp is
not permitted on ARMv4t, for example.
R.
> Martin
>
>
>>
>> etc. That at least would be a concise summary of the options. Whether
>> or not automated tools could handle that is another matter.
>
>
>
>>
>> R.
>>
>>>
>>> Martin
>>>
R.
>
> 0001-Prototype-of-hook-for-possible-list-of-option-values.patch
>
>
> From b2b40f7ca1f801a318aec661d0128a5adde7cb68 Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Fri, 20 Jul 2018 09:58:16 +0200
> Subject: [PATCH] Prototype of hook for possible list of option values.
>
> ---
> gcc/common/common-target.def | 7 +
> gcc/common/common-targhooks.c| 7 +
> gcc/common/common-targhooks.h| 1 +
> gcc/common/config/i386/i386-common.c | 264 +
> gcc/config/i386/i386.c | 413 +++
> gcc/config/i386/i386.h | 144 ++
> gcc/doc/tm.texi | 4 +
> gcc/doc/tm.texi.in | 2 +
> gcc/opt-suggestions.c| 21 +-
> gcc/opts.c | 33 +++
> 10 files changed, 524 insertions(+), 372 deletions(-)
>
> diff --git a/gcc/common/common-target.def b/gcc/common/common-target.def
> index e0afbc6af29..8c98598b015 100644
> --- a/gcc/common/common-target.def
> +++ b/gcc/common/common-target.def
> @@ -80,6 +80,13 @@ DEFHOOK
> bool, (bool report, struct gcc_options *opts),
> hook_bool_bool_gcc_optionsp_false)
>
> +DEFHOOK
> +(get_valid_option_values,
> +"The hook is used for options that have a non-trivial list of\
> + possible option values.",
> + vec,
Re: [PATCH] Prototype of hook for possible list of option values.
On 07/20/2018 12:25 PM, Richard Earnshaw (lists) wrote:
> On 20/07/18 11:14, Martin Liška wrote:
>> On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote:
>>> On 20/07/18 09:04, Martin Liška wrote:
Hi.
I'm sending patch candidate with suggested target common hook. It allows a
target
to list all possible values for an option. Using the API, I implemented
-march and
-mtune option listing on i386.
Richard you asked about the values. Yes, target should list all possible
values,
mainly because --help=target output needs all of these.
Thoughts?
Martin
>>>
>>> I don't think anyone can reasonably write an implementation of this hook
>>> based on this specification:
>>>
>>> +@deftypefn {Common Target Hook} {vec}
>>> TARGET_GET_VALID_OPTION_VALUES (int)
>>> +The hook is used for options that have a non-trivial list of possible
>>> option values.
>>> +@end deftypefn
>>> +
>>>
>>> What's the int parameter for? What's the lifetime of the result (who
>>> cleans it up)? If I need to allocation memory strings in the vector,
>>> where do I do that? Can I assume GC memory in the driver, for example?
>>
>> Sure, can be improved, please take it as prototype.
>>
>>>
>>> Frankly though, I don't really want to enumerate every possible
>>> permutation of the options for the architecture like this, though. It's
>>> just too brute force and the answer is likely to be hundreds (haven't
>>
>> That's why I recommended you to list in --help=target content of
>> arm_arch enum. You replied that it's not complete list of all possible
>> values.
>> Note that we are talking about content of --help option, it's not a
>> documentation,
>> it should just help users. Similar to bash completion, it should not be 100%
>> perfect.
>>
>>> sat down to count it). What's more, the extensions might have meaning
>>> in the order in which they appear. So, for example,
>>>
>>> -march=armv8-a+crypto+nosimd
>>>
>>> would be very different from
>>>
>>> -march=armv8-a+nosimd+crypto
>>>
>>> since the extensions are applied from left to right (the first collapses
>>> to armv8-a+nosimd, the latter to armv8-a+crypto, but there are more
>>> complex cases as well which I don't want to dig into here).
>>>
>>> It would be a practical impossibility to list all of these.
>>
>> Yes, that's why I recommended to list only base march values. Modifiers can
>> be mentioned
>> aside if desired.
>
> So it might be feasible to print something like:
>
> arch1[+ext1|+ext2]*
> arch2[+ext1|+ext3|...]*
This is not feasible for --completion= option (bash completion).
Just for sure, are we talking only about aarch64 feature modifiers. Or do you
have any other
special suffixes used in -march, -mtune, -mcpu option values?
What about listing all possible modifiers after possible values for -march?
Martin
>
> etc. That at least would be a concise summary of the options. Whether
> or not automated tools could handle that is another matter.
>
> R.
>
>>
>> Martin
>>
>>>
>>> R.
>>>
0001-Prototype-of-hook-for-possible-list-of-option-values.patch
From b2b40f7ca1f801a318aec661d0128a5adde7cb68 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 20 Jul 2018 09:58:16 +0200
Subject: [PATCH] Prototype of hook for possible list of option values.
---
gcc/common/common-target.def | 7 +
gcc/common/common-targhooks.c| 7 +
gcc/common/common-targhooks.h| 1 +
gcc/common/config/i386/i386-common.c | 264 +
gcc/config/i386/i386.c | 413 +++
gcc/config/i386/i386.h | 144 ++
gcc/doc/tm.texi | 4 +
gcc/doc/tm.texi.in | 2 +
gcc/opt-suggestions.c| 21 +-
gcc/opts.c | 33 +++
10 files changed, 524 insertions(+), 372 deletions(-)
diff --git a/gcc/common/common-target.def b/gcc/common/common-target.def
index e0afbc6af29..8c98598b015 100644
--- a/gcc/common/common-target.def
+++ b/gcc/common/common-target.def
@@ -80,6 +80,13 @@ DEFHOOK
bool, (bool report, struct gcc_options *opts),
hook_bool_bool_gcc_optionsp_false)
+DEFHOOK
+(get_valid_option_values,
+"The hook is used for options that have a non-trivial list of\
+ possible option values.",
+ vec, (int),
+ default_get_valid_option_values)
+
/* Leave the boolean fields at the end. */
/* True if unwinding tables should be generated by default. */
diff --git a/gcc/common/common-targhooks.c b/gcc/common/common-targhooks.c
index b1090190664..3662180f2e0 100644
--- a/gcc/common/common-targhooks.c
+++ b/gcc/common/common-targhooks.c
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see
#include "tm.h"
Re: [PATCH] Prototype of hook for possible list of option values.
On 20/07/18 11:14, Martin Liška wrote:
> On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote:
>> On 20/07/18 09:04, Martin Liška wrote:
>>> Hi.
>>>
>>> I'm sending patch candidate with suggested target common hook. It allows a
>>> target
>>> to list all possible values for an option. Using the API, I implemented
>>> -march and
>>> -mtune option listing on i386.
>>>
>>> Richard you asked about the values. Yes, target should list all possible
>>> values,
>>> mainly because --help=target output needs all of these.
>>>
>>> Thoughts?
>>> Martin
>>>
>>
>> I don't think anyone can reasonably write an implementation of this hook
>> based on this specification:
>>
>> +@deftypefn {Common Target Hook} {vec}
>> TARGET_GET_VALID_OPTION_VALUES (int)
>> +The hook is used for options that have a non-trivial list of possible
>> option values.
>> +@end deftypefn
>> +
>>
>> What's the int parameter for? What's the lifetime of the result (who
>> cleans it up)? If I need to allocation memory strings in the vector,
>> where do I do that? Can I assume GC memory in the driver, for example?
>
> Sure, can be improved, please take it as prototype.
>
>>
>> Frankly though, I don't really want to enumerate every possible
>> permutation of the options for the architecture like this, though. It's
>> just too brute force and the answer is likely to be hundreds (haven't
>
> That's why I recommended you to list in --help=target content of
> arm_arch enum. You replied that it's not complete list of all possible values.
> Note that we are talking about content of --help option, it's not a
> documentation,
> it should just help users. Similar to bash completion, it should not be 100%
> perfect.
>
>> sat down to count it). What's more, the extensions might have meaning
>> in the order in which they appear. So, for example,
>>
>> -march=armv8-a+crypto+nosimd
>>
>> would be very different from
>>
>> -march=armv8-a+nosimd+crypto
>>
>> since the extensions are applied from left to right (the first collapses
>> to armv8-a+nosimd, the latter to armv8-a+crypto, but there are more
>> complex cases as well which I don't want to dig into here).
>>
>> It would be a practical impossibility to list all of these.
>
> Yes, that's why I recommended to list only base march values. Modifiers can
> be mentioned
> aside if desired.
So it might be feasible to print something like:
arch1[+ext1|+ext2]*
arch2[+ext1|+ext3|...]*
etc. That at least would be a concise summary of the options. Whether
or not automated tools could handle that is another matter.
R.
>
> Martin
>
>>
>> R.
>>
>>>
>>> 0001-Prototype-of-hook-for-possible-list-of-option-values.patch
>>>
>>>
>>> From b2b40f7ca1f801a318aec661d0128a5adde7cb68 Mon Sep 17 00:00:00 2001
>>> From: marxin
>>> Date: Fri, 20 Jul 2018 09:58:16 +0200
>>> Subject: [PATCH] Prototype of hook for possible list of option values.
>>>
>>> ---
>>> gcc/common/common-target.def | 7 +
>>> gcc/common/common-targhooks.c| 7 +
>>> gcc/common/common-targhooks.h| 1 +
>>> gcc/common/config/i386/i386-common.c | 264 +
>>> gcc/config/i386/i386.c | 413 +++
>>> gcc/config/i386/i386.h | 144 ++
>>> gcc/doc/tm.texi | 4 +
>>> gcc/doc/tm.texi.in | 2 +
>>> gcc/opt-suggestions.c| 21 +-
>>> gcc/opts.c | 33 +++
>>> 10 files changed, 524 insertions(+), 372 deletions(-)
>>>
>>> diff --git a/gcc/common/common-target.def b/gcc/common/common-target.def
>>> index e0afbc6af29..8c98598b015 100644
>>> --- a/gcc/common/common-target.def
>>> +++ b/gcc/common/common-target.def
>>> @@ -80,6 +80,13 @@ DEFHOOK
>>> bool, (bool report, struct gcc_options *opts),
>>> hook_bool_bool_gcc_optionsp_false)
>>>
>>> +DEFHOOK
>>> +(get_valid_option_values,
>>> +"The hook is used for options that have a non-trivial list of\
>>> + possible option values.",
>>> + vec, (int),
>>> + default_get_valid_option_values)
>>> +
>>> /* Leave the boolean fields at the end. */
>>>
>>> /* True if unwinding tables should be generated by default. */
>>> diff --git a/gcc/common/common-targhooks.c b/gcc/common/common-targhooks.c
>>> index b1090190664..3662180f2e0 100644
>>> --- a/gcc/common/common-targhooks.c
>>> +++ b/gcc/common/common-targhooks.c
>>> @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see
>>> #include "tm.h"
>>> #include "common/common-target.h"
>>> #include "common/common-targhooks.h"
>>> +#include "opts.h"
>>>
>>> /* Determine the exception handling mechanism for the target. */
>>>
>>> @@ -77,6 +78,12 @@ default_target_handle_option (struct gcc_options *opts
>>> ATTRIBUTE_UNUSED,
>>>return true;
>>> }
>>>
>>> +vec
>>> +default_get_valid_option_values (int option)
>>> +{
>>> + return vec ();
>>> +}
>>> +
>>> const struct default_options empty_optimization_table[] =
>>>{
>>> {
Re: [PATCH] Prototype of hook for possible list of option values.
On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote:
> On 20/07/18 09:04, Martin Liška wrote:
>> Hi.
>>
>> I'm sending patch candidate with suggested target common hook. It allows a
>> target
>> to list all possible values for an option. Using the API, I implemented
>> -march and
>> -mtune option listing on i386.
>>
>> Richard you asked about the values. Yes, target should list all possible
>> values,
>> mainly because --help=target output needs all of these.
>>
>> Thoughts?
>> Martin
>>
>
> I don't think anyone can reasonably write an implementation of this hook
> based on this specification:
>
> +@deftypefn {Common Target Hook} {vec}
> TARGET_GET_VALID_OPTION_VALUES (int)
> +The hook is used for options that have a non-trivial list of possible
> option values.
> +@end deftypefn
> +
>
> What's the int parameter for? What's the lifetime of the result (who
> cleans it up)? If I need to allocation memory strings in the vector,
> where do I do that? Can I assume GC memory in the driver, for example?
Sure, can be improved, please take it as prototype.
>
> Frankly though, I don't really want to enumerate every possible
> permutation of the options for the architecture like this, though. It's
> just too brute force and the answer is likely to be hundreds (haven't
That's why I recommended you to list in --help=target content of
arm_arch enum. You replied that it's not complete list of all possible values.
Note that we are talking about content of --help option, it's not a
documentation,
it should just help users. Similar to bash completion, it should not be 100%
perfect.
> sat down to count it). What's more, the extensions might have meaning
> in the order in which they appear. So, for example,
>
> -march=armv8-a+crypto+nosimd
>
> would be very different from
>
> -march=armv8-a+nosimd+crypto
>
> since the extensions are applied from left to right (the first collapses
> to armv8-a+nosimd, the latter to armv8-a+crypto, but there are more
> complex cases as well which I don't want to dig into here).
>
> It would be a practical impossibility to list all of these.
Yes, that's why I recommended to list only base march values. Modifiers can be
mentioned
aside if desired.
Martin
>
> R.
>
>>
>> 0001-Prototype-of-hook-for-possible-list-of-option-values.patch
>>
>>
>> From b2b40f7ca1f801a318aec661d0128a5adde7cb68 Mon Sep 17 00:00:00 2001
>> From: marxin
>> Date: Fri, 20 Jul 2018 09:58:16 +0200
>> Subject: [PATCH] Prototype of hook for possible list of option values.
>>
>> ---
>> gcc/common/common-target.def | 7 +
>> gcc/common/common-targhooks.c| 7 +
>> gcc/common/common-targhooks.h| 1 +
>> gcc/common/config/i386/i386-common.c | 264 +
>> gcc/config/i386/i386.c | 413 +++
>> gcc/config/i386/i386.h | 144 ++
>> gcc/doc/tm.texi | 4 +
>> gcc/doc/tm.texi.in | 2 +
>> gcc/opt-suggestions.c| 21 +-
>> gcc/opts.c | 33 +++
>> 10 files changed, 524 insertions(+), 372 deletions(-)
>>
>> diff --git a/gcc/common/common-target.def b/gcc/common/common-target.def
>> index e0afbc6af29..8c98598b015 100644
>> --- a/gcc/common/common-target.def
>> +++ b/gcc/common/common-target.def
>> @@ -80,6 +80,13 @@ DEFHOOK
>> bool, (bool report, struct gcc_options *opts),
>> hook_bool_bool_gcc_optionsp_false)
>>
>> +DEFHOOK
>> +(get_valid_option_values,
>> +"The hook is used for options that have a non-trivial list of\
>> + possible option values.",
>> + vec, (int),
>> + default_get_valid_option_values)
>> +
>> /* Leave the boolean fields at the end. */
>>
>> /* True if unwinding tables should be generated by default. */
>> diff --git a/gcc/common/common-targhooks.c b/gcc/common/common-targhooks.c
>> index b1090190664..3662180f2e0 100644
>> --- a/gcc/common/common-targhooks.c
>> +++ b/gcc/common/common-targhooks.c
>> @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see
>> #include "tm.h"
>> #include "common/common-target.h"
>> #include "common/common-targhooks.h"
>> +#include "opts.h"
>>
>> /* Determine the exception handling mechanism for the target. */
>>
>> @@ -77,6 +78,12 @@ default_target_handle_option (struct gcc_options *opts
>> ATTRIBUTE_UNUSED,
>>return true;
>> }
>>
>> +vec
>> +default_get_valid_option_values (int option)
>> +{
>> + return vec ();
>> +}
>> +
>> const struct default_options empty_optimization_table[] =
>>{
>> { OPT_LEVELS_NONE, 0, NULL, 0 }
>> diff --git a/gcc/common/common-targhooks.h b/gcc/common/common-targhooks.h
>> index d290d7f3e21..f8a7436d9dd 100644
>> --- a/gcc/common/common-targhooks.h
>> +++ b/gcc/common/common-targhooks.h
>> @@ -28,6 +28,7 @@ extern bool default_target_handle_option (struct
>> gcc_options *,
>>struct gcc_options *,
>>const
Re: [PATCH] Prototype of hook for possible list of option values.
On 20/07/18 09:04, Martin Liška wrote:
> Hi.
>
> I'm sending patch candidate with suggested target common hook. It allows a
> target
> to list all possible values for an option. Using the API, I implemented
> -march and
> -mtune option listing on i386.
>
> Richard you asked about the values. Yes, target should list all possible
> values,
> mainly because --help=target output needs all of these.
>
> Thoughts?
> Martin
>
I don't think anyone can reasonably write an implementation of this hook
based on this specification:
+@deftypefn {Common Target Hook} {vec}
TARGET_GET_VALID_OPTION_VALUES (int)
+The hook is used for options that have a non-trivial list of possible
option values.
+@end deftypefn
+
What's the int parameter for? What's the lifetime of the result (who
cleans it up)? If I need to allocation memory strings in the vector,
where do I do that? Can I assume GC memory in the driver, for example?
Frankly though, I don't really want to enumerate every possible
permutation of the options for the architecture like this, though. It's
just too brute force and the answer is likely to be hundreds (haven't
sat down to count it). What's more, the extensions might have meaning
in the order in which they appear. So, for example,
-march=armv8-a+crypto+nosimd
would be very different from
-march=armv8-a+nosimd+crypto
since the extensions are applied from left to right (the first collapses
to armv8-a+nosimd, the latter to armv8-a+crypto, but there are more
complex cases as well which I don't want to dig into here).
It would be a practical impossibility to list all of these.
R.
>
> 0001-Prototype-of-hook-for-possible-list-of-option-values.patch
>
>
> From b2b40f7ca1f801a318aec661d0128a5adde7cb68 Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Fri, 20 Jul 2018 09:58:16 +0200
> Subject: [PATCH] Prototype of hook for possible list of option values.
>
> ---
> gcc/common/common-target.def | 7 +
> gcc/common/common-targhooks.c| 7 +
> gcc/common/common-targhooks.h| 1 +
> gcc/common/config/i386/i386-common.c | 264 +
> gcc/config/i386/i386.c | 413 +++
> gcc/config/i386/i386.h | 144 ++
> gcc/doc/tm.texi | 4 +
> gcc/doc/tm.texi.in | 2 +
> gcc/opt-suggestions.c| 21 +-
> gcc/opts.c | 33 +++
> 10 files changed, 524 insertions(+), 372 deletions(-)
>
> diff --git a/gcc/common/common-target.def b/gcc/common/common-target.def
> index e0afbc6af29..8c98598b015 100644
> --- a/gcc/common/common-target.def
> +++ b/gcc/common/common-target.def
> @@ -80,6 +80,13 @@ DEFHOOK
> bool, (bool report, struct gcc_options *opts),
> hook_bool_bool_gcc_optionsp_false)
>
> +DEFHOOK
> +(get_valid_option_values,
> +"The hook is used for options that have a non-trivial list of\
> + possible option values.",
> + vec, (int),
> + default_get_valid_option_values)
> +
> /* Leave the boolean fields at the end. */
>
> /* True if unwinding tables should be generated by default. */
> diff --git a/gcc/common/common-targhooks.c b/gcc/common/common-targhooks.c
> index b1090190664..3662180f2e0 100644
> --- a/gcc/common/common-targhooks.c
> +++ b/gcc/common/common-targhooks.c
> @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see
> #include "tm.h"
> #include "common/common-target.h"
> #include "common/common-targhooks.h"
> +#include "opts.h"
>
> /* Determine the exception handling mechanism for the target. */
>
> @@ -77,6 +78,12 @@ default_target_handle_option (struct gcc_options *opts
> ATTRIBUTE_UNUSED,
>return true;
> }
>
> +vec
> +default_get_valid_option_values (int option)
> +{
> + return vec ();
> +}
> +
> const struct default_options empty_optimization_table[] =
>{
> { OPT_LEVELS_NONE, 0, NULL, 0 }
> diff --git a/gcc/common/common-targhooks.h b/gcc/common/common-targhooks.h
> index d290d7f3e21..f8a7436d9dd 100644
> --- a/gcc/common/common-targhooks.h
> +++ b/gcc/common/common-targhooks.h
> @@ -28,6 +28,7 @@ extern bool default_target_handle_option (struct
> gcc_options *,
> struct gcc_options *,
> const struct cl_decoded_option *,
> location_t);
> +extern vec default_get_valid_option_values (int);
>
> extern const struct default_options empty_optimization_table[];
>
> diff --git a/gcc/common/config/i386/i386-common.c
> b/gcc/common/config/i386/i386-common.c
> index 70b3c3f2fc3..e7253b60c36 100644
> --- a/gcc/common/config/i386/i386-common.c
> +++ b/gcc/common/config/i386/i386-common.c
> @@ -1459,4 +1459,268 @@ i386_except_unwind_info (struct gcc_options *opts)
> #undef TARGET_SUPPORTS_SPLIT_STACK
> #define TARGET_SUPPORTS_SPLIT_STACK ix86_supports_split_stack
>
> +/* This table must be in sync with enum processor_type in i386.h. */
