> On Sat, Oct 6, 2012 at 4:10 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> > Index: passes.c > >> > +/* Hold statistic about profile consistency. */ > >> ... > >> > >> I don't see why this should live in passes.c, can you please put it in > >> a more logical place (profile.c, perhaps)? > > > > Hmm, the problem here is that the code is using passmanager's dumping bits > > to order the passes and assign them names. So moving it elsewhere requires > > exporting it that is not nice. passes.c does similar stuff already, so I > > decided > > to keep it there. > > I think this is not the right decision. We can also throw _all_ code > on one pile because there are inter-dependencies. Or they can be fixed > with a proper interface. > > > If there are no complains I will commit the patch tomorrow. > > +1 complaint. > You're putting profile stuff and even RTL stuff in the pass manager. > That is Just Wrong.
Hmm, the code really is about collecting statistics of individual passes. I do not think it is that different from rest of TODO handling logic, but I do not care much. It is not supposed to be something that will grow over the time and become essential part of the compiler. The code uses the CFG/Gimple/RTL interfaces that are both used by many parts of the compiler (including the passmanager) + passmanager's passes_by_id and passes_by_id_size that are not exported. profile.c is not good place because that is only about reading profile feedback. cfg.c or predict.c seems better because that is where most of cfg/profile API lives. I will probably move it to cfg.c, because it should be in sync with the BB dumping code that should report the same inconsistencies as the statistics loop. Would you preffer exporting profile_record structure and putting the actual walk of CFG into cfg.c or exporting the passmanager's passes_by_id used by the dumping? (actually passes_by_id misses "static" in the declaratoin, so it is matter of putting it to the header) I will implement one of those. Honza > > Ciao! > Steven
