I am hoping that too:) Yes, I will try to do it when I find some time. David
On Wed, Oct 26, 2011 at 1:37 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Tue, Oct 25, 2011 at 9:30 PM, Xinliang David Li <davi...@google.com> wrote: >> >> >> On Tue, Oct 25, 2011 at 1:02 AM, Richard Guenther >> <richard.guent...@gmail.com> wrote: >>> >>> On Mon, Oct 24, 2011 at 6:27 PM, Xinliang David Li <davi...@google.com> >>> wrote: >>> >> Well, you seem to keep not reading what I write. I am not opposed >>> >> to adding -fopt-info/report nor to funnel messages to stdout/err. What >>> >> I am opposed is the way you want to introduce them. I want you to >>> >> fix what we dump into dump files, so that both -fopt-report and >>> >> -fopt-info >>> >> can be implemented by outputting selected pieces of the dump file >>> >> to stdout/stderr. We already have -fdump-*-stats which supposedly >>> >> could match -fopt-report, and the default -fdump-* should be what >>> >> goes to -fopt-info (minus the function bodies, of course). >>> > >>> > That sounds good. What you propose seems like >>> > >>> > -fdump-pass-[ir_only|transformation|debug]-stderr >>> > >>> > and -fopt-info is a short cut for >>> > -fdump-tree-all-transformations-stderr >>> > -fdump-ipa-all-tranformations-stderr >>> > -fdump-rtl-all-transformations-stderr >>> >>> Yes. Note that I don't like it the way the vectorizer does (with >>> -fvectorizer-verbose=... the dump files are empty). The dump >>> file content should be unchanged when redirecting (parts) to >>> stderr, so we have to arrange to duplicate messages in two places. >>> >> Vectorizer dump is a good candidate for clean up when the dumping >> infrastructure improvement is done. >> FYI, for now, we will implement the opt-info for some passes in the simple >> way in google branches, and later migrate to trunk when the dumping >> infrastructure is improved. > > I was hoping you would volunteer to improve the dumping infrastructure. > > Richard. >