This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove global state from gcc/tracer.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]