<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 10:59 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank" class="cremed">hans@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":8r4" style="overflow:hidden"> 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:<br>

<br>
  - Some groups provide HelpText which gets printed by the -help option<br>
<br>
  - 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.<br>

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

<br>
  - 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.<br>
</div></blockquote><div><br></div><div>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).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":8r4" style="overflow:hidden">  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.<br>

<br>
  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)?</div></blockquote></div><br>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:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">f_Group -- compiler "feature" flags. not usually machine-specific, more functionally motivated</div><div class="gmail_extra"><br></div><div class="gmail_extra">
m_Group -- "machine" flags. should never be seen as generic features, but as hardware and machine level stuff</div><div class="gmail_extra"><br></div><div class="gmail_extra">X_Group -- sub-tool flags. -Xclang should be part of this group (and perhaps others)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">---</div><div class="gmail_extra">These groups I think should go:</div><div class="gmail_extra"><br></div><div class="gmail_extra">a_Group -- I have no idea what this is trying to model.</div>
<div class="gmail_extra">L_Group -- I think this was a "language" group, but it doesn't make sense as is. nuke it</div><div class="gmail_extra"><br></div><div class="gmail_extra">---</div><div class="gmail_extra">
For the groups that remain, I think we should try to fix where have been lax about properly categorizing options into them.</div></div>