On 07/08/2015 08:42 PM, Andrew MacLeod wrote:
blah, not so trivial. One of the primary things predict.h does is
create enum br_predictor by including predict,def.. so moving that enum
doesnt really make sense.
Fixing gimple,h isn't too bad, I could split the prediction stuff out
into gimple-predict.h and include it in the 4 places its needed (as you
might be able to tell, Ive tried this :-)
However, it doesn't do much good. cfghooks.h is included by
basic-block.h.. which is needed virtually everywhere :-P
I don't guess we're approaching a world where the front-ends don't need
basic-block (and thus cfghooks, predictions, etc etc).
The other option is to pull cfghooks.h out of basic-block.h and include
it seperately on its own.. What is the reason its in there now? It
appears to not have a cyclic dependency which is the usual reason to
have an include in the middle of a file. Or perhaps the reason no
longer exists? There is a comment at the top of cfghooks.h :
/* Only basic-block.h includes this. */
but no rationale.
I don't recall. It may have seemed to make sense at the time :-) You'd
have to do the archaeology and even if you did, you might not get an answer.
I moved it to the very bottom of the file and everything still seems to
compile fine I can try flattening it out of basic-block.h and only
including it in places that need it... that should eliminate the need to
put predict.h in a lot of places I would think.
If it's not too much trouble, seems like it might be worth trying. It
just feels like the prediction bits shouldn't be that pervasive.
jeff
