On Fri, Jul 26, 2013 at 11:16 AM, Chandler Carruth <[email protected]> wrote: > > On Fri, Jul 26, 2013 at 10:59 AM, Hans Wennborg <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
