[PATCH] Options.td: remove some option groups

[Hans Wennborg]

On Fri, Jul 26, 2013 at 11:16 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
>
> On Fri, Jul 26, 2013 at 10:59 AM, Hans Wennborg <hans at chromium.org> wrote:
>>
>> I've been trying to get my head around the rationale behind the option
>> groups in Options.td. This is how it seems to work currently:
>>
>>   - Some groups provide HelpText which gets printed by the -help option
>>
>>   - Some groups provide functionality, i.e. they're actually referenced by
>> code. For example, the driver will determine its action by looking at the
>> last option in Action_Group, decide the opt level by last option in O_Group,
>> etc.
>>
>>   - Some groups provide functionality by being part of another group. For
>> example, f_Group doesn't provide any functionality in itself, but it's part
>> of CompileOnly_Group which is referenced by code. This means we could
>> s/f_Group/CompileOnly_Group/ without any functionality change.
>>
>>   - Some groups might have a documentary function. For example,
>> m_hexagon_features_Group doesn't actually do anything, but it tells the
>> reader of Optionts.td that options such as -mieee-rnd-near are Hexagon
>> related.
>
>
> I think this use case is still really relevant. You could imagine using this
> to structure a manual page or other generated documentation (maybe even a
> more rich --help output).
>
>
>>   This still leaves us with groups with unclear value. For example, the
>> only purpose of m_Group seems to be to contain all options that start with
>> 'm'. Or most of them; e.g. -maltivec isn't part of m_Group, and others might
>> be missing too - we wouldn't notice since the group doesn't have any real
>> function.
>>
>>   Should we kill the groups that don't have any function or clear
>> documentary purpose (the f_Group and m_Group are the big examples here)?
>
>
> I think we should keep most of these groups, but fix them. Here is a summary
> of the documentation basis for a bunch of the ones that should stay:
>
> f_Group -- compiler "feature" flags. not usually machine-specific, more
> functionally motivated
>
> m_Group -- "machine" flags. should never be seen as generic features, but as
> hardware and machine level stuff
>
> X_Group -- sub-tool flags. -Xclang should be part of this group (and perhaps
> others)

Sounds reasonable.

> These groups I think should go:
>
> a_Group -- I have no idea what this is trying to model.
> L_Group -- I think this was a "language" group, but it doesn't make sense as
> is. nuke it

Right, I'll do that with this patch.

 - Hans