On Thu, May 23, 2013 at 11:42 PM, Jeff Law <l...@redhat.com> wrote: > 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.
Without looking at the actual patch in question I'd say that changing things in a way that is clearly defined where we'd be thread safe is a good thing. For example after the frontend finished, or after the point where LTO would have run, or for all IPA analysis/transform phases (who usually iterate over all function bodies). Ideally we'd be able to work on multiple functions at once. The very first step in that direction would be to kill current_pass and have the pass manager pass in context (containing the struct function to work on for example, replacing uses of cfun) to the execute function of scalar passes. And then just conentrate on getting rid of (implicit) 'cfun' uses in passes (let them flag themselves with "I'm safe w/o cfun" and have the pass manager just NULL that). A lot of interfaces got a _fn variant already. Then of course interesting things such as dumpfiles pop up - a pass writes to a single dump-file, so multiple instances of that pass cannot run in parallel without disrupting that. A way out is to run in a pipelining mode instead, thus have only a single pass instance at a given time but have multiple functions being processed by different passes in parallel. That even avoids the need to cleanup state in passes themselves, it just needs caretaking of the global cfun like state. Richard. > Jeff
