Re: [patch 0/9] Flattening and initial module rebuilding

[Jeff Law <law at redhat dot com>]

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