On 07/07/2015 05:53 PM, Andrew MacLeod wrote:
yes, with a bit of tweaking and enhancement they can be generally
useful. They are all in python. And no one is allowed to make comments
like "OMG thats so inefficient" or "what a horrible way to do that"
:-) My goal was getting things done and sometimes the brute force
approach works great when the machine sare fast enough :_)
Works for me... I'm sure Martin S. is cringing at my python scripts
right now, so I completely understand.
It's a bit of a shame that function.h is in backend.h, along with
predict (which is presumably needed by basic-block/cfg?).
Yeah,once things settle down someone could tweak things more. If I make
the tools available, people can do their own analysis and adjusting.
function.h provides cfun which is used all over the place..9 backend
header files use it,and a few like gimple.h actually require struct
function to be defined.
Right. I suspect that we may want to look at cleaning that up a bit in
the future. There's bits in there that are relatively backend specific,
some bits that look like front-end things, and cfun which is a context
container. Untangling that mess is likely to be painful.
predict.h is actually required by gimple.h for a few reasons, enum
be_predictor is used in parameter lists and a few inlines use the TAKEN,
NOT_TAKEN macros
Its also needed by cfghooks.h, and betwen those 2 files, its just needed
by a very good chunk of the backend. .. 219 of the 263 files which
include backend.h need it.
We could move the 2 enums and TAKEN/NOT_TAKEN to coretypes or something
like that and it would probably cut the requirements for it by a *lot*.
Might be something for a follow-up (moving the enums).
Jeff
