public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Alexander Monakov <amonakov@ispras.ru>,
	 Joseph Myers <joseph@codesourcery.com>,
	Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] clarify documentation of -Q --help=optimizers
Date: Fri, 06 Nov 2015 01:25:00 -0000	[thread overview]
Message-ID: <563C0185.5030607@gmail.com> (raw)
In-Reply-To: <20151105233006.GA27541@gate.crashing.org>

On 11/05/2015 04:30 PM, Segher Boessenkool wrote:
> On Thu, Nov 05, 2015 at 02:04:47PM -0700, Martin Sebor wrote:
>> On 11/05/2015 10:09 AM, Segher Boessenkool wrote:
>>> On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
>>>> I don't think that reiterating in a condensed form what the manual
>>>> doesn't make clear in many more words will help. First, even users
>>>> who do find the relevant text in the manual often misunderstand it.
>>>> Others are misled by the "[enabled]" output into expecting the
>>>> optimizations to take place at -O0.
>>>
>>> The -Q --help* output is primarily aimed at GCC developers, just
>>> like plain -Q is.  The main problem here seems to be that the
>>> documentation pushes beginner GCC users to use this.
>>>
>>> Perhaps we should have a higher-level, more easy to use way to query
>>> what flags will do what, possibly integrated with the pass manager.
>>
>> I think that would be ideal (i.e., hiding each flag_xxx under
>> a get_flag_xxx() and set_flag_xxx() interface that would make
>> it possible to compute and dynamically query individual option
>> settings based on non-trivial dependencies). It strikes me as
>> quite a project.
>
> I was thinking more of showing at every flag whether it is relevant at
> all, or maybe not showing irrelevant ones except maybe when some
> --verbose or so option is given; and if you want to get really fancy
> (but also very helpful to both users and developers), have some option
> that shows all dependencies for a flag to take effect.
>
> This of course requires expressing some dependencies manually in the
> .opt files, but hopefully most can be done automatically with some
> magic.

Yes, the dependencies would have to be encoded somewhere, somehow
(once they were discovered, which seems like a challenge in and
if itself). Since they could be non-trivial (one option being
enabled by several others), to be sufficiently general, the data
structure itself would need to be able to express that any given
option is can be enabled or disabled by any combination of others.

>
>>>> Those who are in doubt and
>>>> ask on gcc-help are then told by GCC experts that -O0 disables
>>>> all optimizations without exception,
>>>
>>> And it does, for the plain meaning of "optimization"; anything else
>>> is arguably a bug.  But people have many different understandings
>>> of what a "compiler optimization" is, all the way to "anything the
>>> compiler does".
>>
>> Yes, that also sometimes causes confusion, though it's not something
>> I'm trying to solve with this patch.
>
> It's not something you _can_ solve as far as I see.  There is a
> considerable gap between what beginner and advanced users expect from
> the compiler, understand about the compiler, and worst of all, think
> they understand about the compiler.  GCC should be a useful compiler
> to that whole spectrum of audiences.  Currently -Q --help shows just
> the gory details, which is functionality we want to keep IMO, but not
> something we want to recommend everyone to use.
>
> Does that make sense?  I'm not sure I'm expressing myself well here,
> you cannot see my frantic handwaving :-)

It does make sense (even without the handwaving, though picturing
it in my mind was a big help :) I agree that solving this bigger
problem is well beyond what can be accomplished by changing the
compiler or its documentation.

Martin

  reply	other threads:[~2015-11-06  1:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56299713.6040204@gmail.com>
2015-10-23  3:56 ` Martin Sebor
2015-11-02 21:48   ` [PING] " Martin Sebor
2015-11-03 10:19   ` Alexander Monakov
2015-11-04 23:52     ` Martin Sebor
2015-11-05  0:54       ` Joseph Myers
2015-11-05 10:48         ` Alexander Monakov
2015-11-05 15:58           ` Martin Sebor
2015-11-05 17:09             ` Segher Boessenkool
2015-11-05 21:04               ` Martin Sebor
2015-11-05 23:30                 ` Segher Boessenkool
2015-11-06  1:25                   ` Martin Sebor [this message]
2015-11-05 17:11             ` Joseph Myers
2015-11-05 17:47               ` Martin Sebor
2015-11-05 18:07                 ` Joseph Myers
2015-11-05 18:45                   ` Martin Sebor
2015-11-05 18:47                     ` Joseph Myers
2015-11-05  1:09       ` Sandra Loosemore
2015-11-05  2:40         ` Martin Sebor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563C0185.5030607@gmail.com \
    --to=msebor@gmail.com \
    --cc=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).