This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Xinliang David Li <davidxl at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>, Teresa Johnson <tejohnson at google dot com>
- Date: Wed, 7 Aug 2013 23:54:42 +0000
- Subject: Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....
- References: <CAAkRFZLZh1q+p55O6kA3QSgyNERcPpAOW=tpWYye40Dzs+0KcA at mail dot gmail dot com> <f577b371-1d7e-4fd1-b26e-c8541aa54838 at email dot android dot com> <874nb55usp dot fsf at tassilo dot jf dot intel dot com>
On Sun, 4 Aug 2013, Andi Kleen wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
> >
> > The patch fails to add documentation.
>
> That seems like a feature, it's likely not useful for the general
> public. More for specialized tools that automatically search
> for the best tuning.
If such a tool is not part of GCC itself, then it is a user of GCC and
documentation should be provided for those writing such a tool.
Options should be undocumented in very limited cases such as multiple
variant spellings where only one should be used but others are accepted
because they were historically, or whether the user interface to an option
is separate from the internal option passed to cc1 (the documentation is
of options as passed to the driver, but the .opt file may describe options
passed to cc1 as a result of other options being passed to the driver), or
the option really is only for use within the build of GCC itself.
Otherwise, the strong presumption is that all options should be
documented, with appropriate caveats as applicable about the cases where
an option is useful.
> > And I am nervous about testing
> > coverage - is this considered a development option only or are random
> > combinations expected to work in all situations? I expect not, thus
> > this looks like a dangerous option?
>
> When it's undocumented it doesn't need to work in every situation?
No input files and command-line arguments whatsoever to the driver should
result in ICEs, including undocumented options.
--
Joseph S. Myers
joseph@codesourcery.com