On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li <davi...@google.com> wrote: >> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther >> <richard.guent...@gmail.com> wrote: >>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li <davi...@google.com> >>> wrote: >>>> The following patch implements the a new option that dumps gcc PASS >>>> configuration. The sample output is attached. There is one >>>> limitation: some placeholder passes that are named with '*xxx' are >>>> note registered thus they are not listed. They are not important as >>>> they can not be turned on/off anyway. >>>> >>>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list >>>> of function assembler names to be specified. >>>> >>>> Ok for trunk? >>> >>> Please split the patch. >>> >>> I'm not too happy how you dump the pass configuration. Why not simply, >>> at a _single_ place, walk the pass tree? Instead of doing pieces of it >>> at pass execution time when it's not already dumped - that really looks >>> gross. >> >> Yes, that was the original plan -- but it has problems >> 1) the dumper needs to know the root pass lists -- which can change >> frequently -- it can be a long term maintanance burden; >> 2) the centralized dumper needs to be done after option processing >> 3) not sure if gate functions have any side effects or have dependencies on >> cfun >> >> The proposed solutions IMHO is not that intrusive -- just three hooks >> to do the dumping and tracking indentation. > > Well, if you have a CU that is empty or optimized to nothing at some point > you will not get a complete pass list. I suppose optimize attributes might > also confuse output. Your solution might not be that intrusive > but it is still ugly. I don't see 1) as an issue, for 2) you can just call > the > dumping from toplev_main before calling do_compile (), 3) gate functions > shouldn't have side-effects, but as they could gate on optimize_for_speed () > your option summary output will be bogus anyway. > > So - what is the output intended for if it isn't reliable?
This needs to be cleaned up at some point -- the gate function should behave the same for all functions and per-function decisions need to be pushed down to the executor body. I will try to rework the patch as you suggested to see if there are problems. David > > Richard. > >>> >>> The documentation should also link this option to the -fenable/disable >>> options as obviously the pass names in that dump are those to be >>> used for those flags (and not readily available anywhere else). >> >> Ok. >> >>> >>> I also think that it would be way more useful to note in the individual >>> dump files the functions (at the place they would usually appear) that >>> have the pass explicitly enabled/disabled. >> >> Ok -- for ipa passes or tree/rtl passes where all functions are >> explicitly disabled. >> >> Thanks, >> >> David >> >>> >>> Richard. >>> >>>> Thanks, >>>> >>>> David >>>> >>> >> >
