No documentation of -fsched-pressure-algorithm

[David Brown]

On 01/05/2012 20:11, Joern Rennecke wrote:
> Quoting Richard Sandiford <rdsandiford@googlemail.com>:
>
>> nick clifton <nickc@redhat.com> writes:
>>> OK, but what if it turns out that the new algorithm improves the
>>> performance of some benchmarks/applications, but degrades others, within
>>> the same architecture ? If that turns out to be the case (and I suspect
>>> that it will) then having a documented command line option to select the
>>> algorithm makes more sense.
>>
>> That was my point though. If that's the situation, we need to find
>> out why. We shouldn't hand the user a long list of options and tell
>> them to figure out which ones happen to produce the best code.
>
> Actually, having a long list of things that you can tweak is exactly what
> Milepost thrives on.
>
>> Well, given the replies from you, Ian and Vlad (when reviewing the
>> patch),
>> I feel once again in a minority of one here :-) but... I just don't
>> think we should be advertising this sort of stuff to users. Not because
>> I'm trying to be cliquey, but because any time the user ends up having
>> to use stuff like this represents a failure on the part of the compiler.
>
> We have mis-fireing heuristics all over the place. This has actually
> gotten a lot worse with the shift from rtl to tree optimizers. These
> days the optimizers know how to do almost any transformation, but squat
> about the cost/benefit equation.
>
> But I don't see how hiding the switches to force the heuristics makes
> this situation any better.
>
>> I mean, at what level would we document it? We could give a detailed
>> description of the two algorithms, but there should never be any need
>> to explain those to users (or for the users to have to read about them).
>> And there's no guarantee we won't change the algorithms between releases.
>> So I suspect we'd just have documentation along of the lines of
>> "here, we happen to have two algorithms to do this. Treat them as
>> black boxes, try each one on each source file, and see what works
>> out best." Which isn't particularly insightful and not IMO a good
>> user interface.
>
> It's not ideal, but workable. If you could explain coherently when the
> option should be used, you could probably improve the heuristics already.
> If you want to make this a bit more meaningful, you could have a bugzilla
> bug for the imperfect heuristics, and ask people to submit their testcases
> when they see significant benefit from using an obscure option.
>

One thing that might be nice is to split the documentation pages a 
little, such as into "normal user options", "advanced user options", and 
"here be dragons".  gcc has a /lot/ of options, many of which are of 
little use to most users, and it can be overwhelming to see so many on 
the same page of the manual.  If you made a "here be dragons" page, it 
would make it much easier to have only rough information there.  The 
page would start with a disclaimer that these options are for expert 
usage and testing, they can change at any time in different versions of 
gcc, and users should not expect support from suppliers (Code Sourcery, 
Red Hat, etc.) on their usage.  Then you could add limited documentation 
for options like "-fsched-pressure-algorithm" or the various "--param" 
options, with just a rough explanation.  It doesn't really matter if the 
explanation is incomprehensible to mortal users - and it may even just 
be a link to a gcc wiki page or part of the gcc internals documentation.

A second thing that would be hugely convenient for advanced users and 
testers (and people like me who just like to read manuals) would be a 
version number attached to each option, so that we can see which gcc 
versions support it.  Some of us use multiple gcc versions (I do 
embedded work - I have gcc for different targets with versions ranging 
from 2.95 to 4.6) - it would be /very/ nice to be able to look at the 
latest version of the documentation rather than always having to go back 
to old versions to figure out if a particular option exists in that 
particular version.

mvh.,

David