-fdump-passes -fenable-xxx=func_name_list

Xinliang David Li davidxl@google.com
Thu Jun 2 07:13:00 GMT 2011


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 <davidxl@google.com> wrote:
> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li <davidxl@google.com> wrote:
>>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li <davidxl@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
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-pass3.p
Type: application/octet-stream
Size: 7243 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110602/8be5289f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out
Type: application/octet-stream
Size: 14902 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110602/8be5289f/attachment-0001.obj>


More information about the Gcc-patches mailing list