This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Continue stmt branch prediction
- From: Bradley Lucier <lucier at math dot purdue dot edu>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Bradley Lucier <lucier at math dot purdue dot edu>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 20 Feb 2008 16:45:54 -0500
- Subject: Re: Continue stmt branch prediction
Re:
What are the other predictors? It might help to understand it
better if we had a better overview of everything PREDICT_EXPR was
going to do.
I was mostly looking into following stuff:
1) the continue bit
2) explicit goto statements are usually not executed
3) default path of C switch statement on emum with all named fields
explicit is unlikely
4) expanded bounds checks (ie arrays tends to be in bounds. We
used to
have PRED_MUDLFAP here but it was dropped and Java has similar
logic)
5) expanded openMP constructs
6) higher level constructs from non-C frontends we have. There are
cases where we produce control flow expanding stuff like fortran
vectors where we have unlikely paths through. Though I didn't look
into great detail into this yet.
Honza:
Computer-generated C code as the back end of compilers for other
languages may implement function calls as gotos (the callee, not the
caller, controls the argument stack in Scheme, for example, so The
Gambit Scheme->C compiler generate C code where function calls are
just goto's with arguments). It appears that heuristics such as 2
may make such code perform worse (especially as incorrectly-predicted
jumps have such a high cost on some processors).
Are there predictors already implemented in gcc based on other
things, such as control flow graphs?
If gcc does adopt heuristics such as these, I hope they can be
documented so that people automatically generating C code can either
exploit them or avoid them as necessary. (An example is that the
Gambit Scheme compiler has been generating SSA-style floating-point
code for years because the original code generator produced code that
gcc's register allocator didn't handle very well.)
Brad