Remove global state from gcc/tracer.c

[Jeff Law]

On 05/23/2013 02:59 PM, Jakub Jelinek wrote:
> 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.
Nor do we have the luxury of continuing to not deal with these long term 
issues.  Nor do we have the luxury of creating something so (*&@#$ ugly 
that nobody is willing to work on it again in the future.   Particularly 
when there's no evidence it's going to be measurably slower.


>
> 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.
Agreed, but we need to start somewhere and passes of this nature seem 
like a reasonable place to me


   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).
I don't disagree in principle WRT partial transformations.  But I also 
believe that there is value in cleaning up the the simple stuff, even in 
isolation.

To take your specific examples:

   * Global state is global state needs to be available via
   a global context pointer of some kind regardless of how we
   handle pass-local data.

   * pass-local state that spans passes.  I'd like to see an
   example, but my gut feeling is such things are probably
   going to either become global state or die.  They'll have
   to be handled on a case by case basis.

In both cases, David's changes don't make those problems any easier or 
any harder.  He merely encapsulates pass-local data where it's easy to 
do so right now.  It's just a cleaner design/implementation and I'd like 
to see it pursued.

Jeff