On Wed, Jun 6, 2012 at 10:58 PM, Sharad Singhai <sing...@google.com> wrote: > Sorry about the delay. I have finally incorporated all the suggestions > and reorganized the dump infrastructure a bit. The attached patch > updates vectorizer passes so that instead of accessing global > dump_file directly, these passes call dump_printf (FLAG, format, ...). > The dump_printf can choose between two streams, one regular pass dump > file, and another optional command line provided file. Currently, it > doesn't discriminate and all the dump information goes to both the > streams. > > Thus, for example, > > g++ -O2 v.cc -ftree-vectorize -fdump-tree-vect=foo.v > -ftree-vectorizer-verbose=3
But the default form of dump option (-fdump-tree-vect) no longer interferes with -ftree-vectorize-verbose=xxx output right? (this is one of the main requirements). One dumped to the primary stream (named dump file) and the other to the stderr -- the default diagnostic (alt) stream. David > > will output the verbose vectorizer information in both *.vect file and > foo.v file. However, as I have converted only vectorizer passes so > far, there is additional information in *.vect file which is not > present in foo.v file. Once other passes are converted to use this > scheme, then these two dump files should have identical output. > > Also note that in this patch -fdump-xxx=yyy format does not override > any auto named dump files as in my earlier patches. Instead the dump > information is output to both places when a command line dump file > option is provided. > > To summarize: > - instead of using dump_begin () / dump_end (), the passes should use > dump_start ()/dump_finish (). These new variants do not return the > dump_file. However, they still set the global dump_file/dump_flags for > the benefit of other passes during the transition. > - instead of directly printing to the dump_file, as in > if (dump_file) > fprintf (dump_file, ...); > > The passes should do > > dump_printf (dump_flag, ...); > This will output to dump file(s) only when dump_flag is enabled for a > given pass. > > I have bootstrapped and tested it on x86_64. Does it look okay? > > Thanks, > Sharad > > > On Mon, May 14, 2012 at 12:26 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Sat, May 12, 2012 at 6:39 PM, Xinliang David Li <davi...@google.com> >> wrote: >>> On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis >>> <g...@integrable-solutions.net> wrote: >>>> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li <davi...@google.com> >>>> wrote: >>>> >>>>> The downside is that the dump file format will look different from the >>>>> stderr output which is less than ideal. >>>> >>>> BTW, why do people want to use stderr for dumping internal IRs, >>>> as opposed to stdout or other files? That does not sound right. >>>> >>> >>> I was talking about the transformation information difference. In >>> stderr (where diagnostics go to), we may have >>> >>> foo.c: in function 'foo': >>> foo.c:5:6: note: loop was vectorized >>> >>> but in dump file the format for the information may be different, >>> unless we want to duplicate the machinery in diagnostics. >> >> So? What's the problem with that ("different" diagnostics)? >> >> Richard. >> >>> David >>> >>>> -- Gaby