This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: No documentation of -fsched-pressure-algorithm


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]