On Thu, May 23, 2013 at 02:44:48PM -0600, Jeff Law wrote:
> On 05/23/2013 02:31 PM, Richard Henderson wrote:
> >I think we need more weigh in from other maintainers on this, rather than
> >iterating a 5th time today...
> This seems like an awful lot of pain.
>
> I don't think we should be looking to generate different code for
> library vs executable GCC.
>
> I think we should look for *clean* first, then we can look at what
> we could change if the compile-time performance isn't what we want.
>
> Lots of C++ code manages to pass around the implicit this pointer
> and use it appropriately without that being a significant source of
> performance concerns. I suspect GCC would be the same in that
> regard. The cost of passing around & using that pointer is dwarfed
> by all the other lameness we have.
I'm afraid we don't have the luxury of slowing the compiler too much.
Anyway, I don't see how a single this would help with all the global state,
because there are various levels of global state. The tracer changes show
just the easiest one, non-GTY pass that that is internal to the file,
starts living at the start of the pass and can be forgotten at the end of
the pass. But, often pass has some of its global state, and calls functions
from other files that access different global state (cfun, crtl,
current_function_decl, lots of other things), some files have global state
preserved across multiple passes, etc. Before we start changing anything,
we need a firm plan for everything, otherwise we end up with a useless
partial transformation. Some global state data is accessed only
occassionally, but other is accessed all the time (cfun being a very good
example here).
Jakub
