[PATCH] Options.td: remove some option groups

[Chandler Carruth]

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)

---
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

---
For the groups that remain, I think we should try to fix where have been
lax about properly categorizing options into them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130726/76079022/attachment.html>