Dump before flag

Xinliang David Li davidxl@google.com
Wed Jun 8 06:44:00 GMT 2011

The attached is the proposed patch to split dump files. Example:

gcc -O2 -fdump-tree-ccp1-before-after fre.c

Produces three files:

BEFORE ccp1 IR file: fre.c.023t.ccp1.before
AFTER ccp1 IR file: fre.c.023t.ccp1.after
debug dump file: fre.c.023t.ccp1 (also include the finish IR)

gcc -O2 -fdump-tree-ccp1-before-finish fre.c

BEFORE ccp1 IR file: fre.c.023t.ccp1.before
IR dump after ccp1 is finished (include post cleanups): fre.c.023t.ccp1.finish
debug (only debug) dump file: fre.c.023t.ccp1

gcc -O2 -fdump-tree-ccp1

behaves as before.

Please comment.



On Tue, Jun 7, 2011 at 4:16 PM, Xinliang David Li <davidxl@google.com> wrote:
> It might be also useful to implement the dumping behavior like this:
> if any of the start/before/after/finish option is explicitly
> specified, IR (and only IR) will be dumped into files suffixed with
> .start/.before/.after/.finish. The debug dump will be dumped as usual
> into the non suffixed file name. By default, the IR dump and debug
> dump will be dumped into the same file which is the current behavior.
> David
> On Tue, Jun 7, 2011 at 4:08 PM, Xinliang David Li <davidxl@google.com> wrote:
>> The following is the patch that does the job. Most of the changes are
>> just  removing TODO_dump_func. The major change is in passes.c and
>> tree-pass.h.
>> -fdump-xxx-yyy-start       <-- dump before TODO_start
>> -fdump-xxx-yyy-before    <-- dump before main pass after TODO_pass
>> -fdump-xxx-yyy-after       <-- dump after main pass before TODO_finish
>> -fdump-xxx-yyy-finish      <-- dump after TODO_finish
>> The default is 'finish'.
>> Does it look ok?
>> Thanks,
>> David
>> On Tue, Jun 7, 2011 at 2:36 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li <davidxl@google.com> wrote:
>>>>> Your patch doesn't really improve this but adds to the confusion.
>>>>> +  /* Override dump TODOs.  */
>>>>> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
>>>>> +      && (dump_flags & TDF_BEFORE))
>>>>> +    {
>>>>> +      pass->todo_flags_finish &= ~TODO_dump_func;
>>>>> +      pass->todo_flags_start |= TODO_dump_func;
>>>>> +    }
>>>>> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
>>>>> looks misplaced as it controls TODOs, not dumping behavior.
>>>>> Yes, it's a mess right now but the above looks like a hack ontop
>>>>> of that mess (maybe because of it, but well ...).
>>>> How about removing dumping TODO completely -- this can be done easily
>>>> -- I don't understand why pass wants extra control on the dumping if
>>>> user already asked for dumping -- it is annoying to see empty IR dump
>>>> for a pass when I want to see it.
>>>>> At least I would have expected to also get the dump after the
>>>>> pass, not only the one before it with this dump flag.
>>>>> Now, why can't you look at the previous pass output for the
>>>>> before-dump (as I do usually)?
>>>> For one thing, you need to either remember what is the previous pass,
>>>> or dump all passes which for large files can take very long time. Even
>>>> with all the dumps, you will need to eyeballing to find the previous
>>>> pass which may or may not have the IR dumped.
>>>> How about removing dump TODO?
>>> Yeah, I think this would go in the right direction.  Currently some passes
>>> do not dump function bodies because they presumably do no IL
>>> modification.  But this is certainly the minority (and some passes do not
>>> dump bodies even though they are modifying the IL ...).
>>> So I'd say we should by default dump function bodies.
>>> Note that there are three useful dumping positions (maybe four),
>>> before todo-start, after todo-start, before todo-finish and after todo-finish.
>>> By default we'd want after todo-finish.  When we no longer dump via
>>> a TODO then we could indeed use dump-flags to control this
>>> (maybe -original for the body before todo-start).
>>> What to others think?
>>> Richard.
>>>> Thanks,
>>>> David
>>>>> Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-control-2.p
Type: text/x-pascal
Size: 78517 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110608/d4073958/attachment.bin>

More information about the Gcc-patches mailing list