This is the mail archive of the
mailing list for the GCC project.
Re: No documentation of -fsched-pressure-algorithm
Quoting Richard Sandiford <email@example.com>:
nick clifton <firstname.lastname@example.org> 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
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.