Is this one ok? Thanks,
David On Thu, Jun 2, 2011 at 12:12 AM, Xinliang David Li <davi...@google.com> wrote: > This is the version of the patch that walks through pass lists. > > Ok with this one? > > David > > On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li <davi...@google.com> wrote: >> 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 >>>>>> >>>>> >>>> >>> >> >
