No documentation of -fsched-pressure-algorithm

[Joern Rennecke]

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.