Re: Using .opt files for target options

[Richard Sandiford <rsandifo at redhat dot com>]

Zack Weinberg <zack@codesourcery.com> writes:
> Richard Sandiford <rsandifo@redhat.com> writes:
>> The aim of this patch is to extend the front- and middle-end
>> options-handling machinery so that it can be used for target
>> options as well.  In other words, it lets you specify target
>> options using target-specific .opt files.
>
> I'm very glad to see this happen.  Your code generally looks sound,
> and Neil has already approved it, but there's a detail I'd like to
> bring up.  You've currently got a special case in the flag_var logic
> to handle target_flags_explicit.  That's fine as far as it goes, but
> it doesn't help with anything that's currently being done with
> TARGET_OPTIONS, nor with things that are moved out of target_flags
> after conversion to an .opt file.  Also, it still requires special
> handling in OVERRIDE_OPTIONS.
>
> What target_flags_explicit does (assuming OVERRIDE_OPTIONS handles it)
> is allow the user to not worry about the order of general and specific
> -m options.  Really, what we want is to impose a partial ordering on
> the -m options, so that general ones (-march= e.g.) are processed
> before specific ones (-mgp64 e.g.)  I wonder if you have any ideas how
> to handle that...?

Well, I see target_flags_explicit as the target_flags equivalent
of initialising a flag_foo variable to -1.  They're both ways of
telling whether an option's state has been set explicitly.  I have
to admit that I personally don't have a problem with either.

Also, the current behaviour of the -m options is pretty easy to
document at the user level: (1) they are processed left-to-right
and (2) the default values of some options depend on other
controllable properties, such as the selected architecture or ABI.
A partial ordering sounds more like a multi-level thing.

Richard