On Thu, Apr 04, 2013 at 10:42:47AM +0200, Richard Biener wrote:
> I originally thought of using namespaces to fend off pass-specific globals,
> but eventually moving it all to a pass specific class would work, too.
>
> Note that there are some passes that have global data that is allocated
> and initialized once per compilation, so the pass class objects will
> probably not be short-lived (like construct / destruct per pass invocation
> which would be the cleanest design IMHO, at least for pass local data
> lifetime management ...). Thus eventually the 'pass' object should be
> split into a global and per invocation object?
But you don't want to pass around to all functions two extra pointers (for
global and per invocation object). Also, some of the global state, even the
intra-pass ostate that is initialized once, is GTY, we'd need to somehow
arrange for that to be walked by GC.
Passing this or context pointers to half of the functions in the compiler
might be quite expensive, wonder if just making all the global vars __thread
when building the library variant (in form of some macro that would expand
to nothing for the supposedly faster compiler binary) wouldn't be cheaper,
if you run the whole or most of the optimization pipeline, you probably
aren't going to interrupt it many times and run 3 passes on CU 1, 3 passes
on CU 2, 3 passes on CU 3 in the same thread.
Jakub
