Re: New attribute "infrequent"?

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka <jh@suse.cz> writes:
> 
> > Changing something else than -Ox to -Os is dificult to do - in
> > general lots of our code initializes costs and various settings on
> > the startup of compiler.
> 
> You are arguing that the compiler does certain things are done in the
> compiler and that they are hard to change and conclude it is not good
> to change it.  It harder to change it, yes.
I don't conclude that it is not good - I was just trying to explain, that
the "infrequent" attribute can serve complementary role to way switching
attributes. I would like to implement something like "infrequent", while I would
not want to implement the option controlling (definitly not on BB level),
as it is dificult.
> 
> Fact is that function-level attribution only works for very
> disciplined programming and even then there are reasons to not do it
> (attribution should not only allow to predict infrequent use, also
> very frequent use should be predictable.
> 
> So while your goal is to add something on function-level I still
> maintain that C-block level is needed as well.
This is like with the "const" function attribute. Similar idea can
be generalized to "pure" attribute, or it can be benefical to say that
fucntion never use double indirection, such as str function do,
or it can be nice to list global variables modified etc.

One needs to stop at some level. While "infrequent" attribute is something
to implement in one afternoon, allowing arbitary compiler configuration
changes would require a lot more. Also as mentioned by Gerald extensive
use of such an feature has large maitenance costs - the switches changes
from compiler to compiler and thus maitenance of such code may be dificult.

What I am hoping for is that "infrequent" is capturing one of most important
aspects and is usefull hint to compiler easy to understand for programmer to
use it.

As I've mentioned in the first email, it may make more sense to have attribute
"frequent" as 80% or so of code is infrequent and it can be dificult to mark
it.  Current way in compiler is to assume that everything is "frequent" and
optimize it as hard as possible, so it is dificult to customary optimize
something even harder.

In perofrmance critical programs, the profile feedback is probably way to go.
The role of "infrequent" attribute is more for the library purposes, where
generating profile runs for each possible program is dificult and it can
serve the role of hints for predicting branches in user programs.
> 
> > > Using __builtin_expect we can control the block ordering (though this
> > > should be improved on as well) but as you say, aggressive
> > In what way? I am just working in this area so it can be nice.
> 
> Cannot reproduce it in a small test case.  glibc uses __builtin_expect
> extensively and the reordering not always takes this hint serious.
> Short if-blocks of a negatively predicted if are still generated in
> line instead of somewhere else.  This really should be unconditional.
Hmm, having testcase can be nice.  The builtin_expect first generates the
branch and then attemps to parse the resulting code and find the conditional.
This does not always match - perhaps we can add an warning, like we do for
failed inlining.  For user, adding __builtin_expect is lots of work and
he would be definitly disapointed to see it ignored.

Honza
> 
> -- 
> ---------------.                          ,-.   1325 Chesapeake Terrace
> Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
> Red Hat          `--' drepper at redhat.com   `------------------------