On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai <sing...@google.com> wrote: > Hi, > > The new dump infrastructure was committed shortly before the trunk > entered stage 3. > > However, except the vectorization passes, other passes do not dump > anything in response to -fopt-info flags despite the documentation. I > can prepare patches for a couple more passes so that they output more > meaningful information, otherwise, the -fopt-info would remain largely > useless in 4.8. Also I suspect some other passes can be converted > relatively easily to use the new dump scheme. > > Would it be acceptable to consider -fopt-info patches in stage 3? If > yes, I can send out a more detailed message about the conversion and > solicit for help.
It should be decided on a case-by-case basis. What passes do you have in mind that people are usually interested in in the context of -fopt-info? Richard. > Thanks, > Sharad > > On Fri, Oct 19, 2012 at 12:19 PM, Sharad Singhai <sing...@google.com> wrote: >> On Fri, Oct 19, 2012 at 12:03 PM, Xinliang David Li <davi...@google.com> >> wrote: >>> The one taking argument is changed to dump_enabled_phase (Sharad, >>> should it be dump_enabled_phase_p ?). >> >> Yes, I renamed the old method to dump_enabled_phase. I would rename it >> further to dump_enabled_p to make it clear. >> >>> >>> Sharad, it may be better to throwing first a trivial patch that >>> introduces dump_enabled_p () without argument, and leave the clean up >>> of vectorizer code as a separate one. Do this earlier so that other >>> contributors have time to cleanup the dumps. Please also resend to the >>> email list to summarize the new standard way of debug/msg dump. >> >> Yes, I would do that. >> >> Thanks, >> Sharad >> >>> >>> thanks, >>> >>> David >>> >>> On Fri, Oct 19, 2012 at 3:11 AM, Richard Biener >>> <richard.guent...@gmail.com> wrote: >>>> On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai <sing...@google.com> wrote: >>>>>> You still have the issue that // regular stuff may appear to possibly >>>>>> clobber any_dump_enabled_p and thus repeated any_dump_enabled_p >>>>>> checks are not optimized by the compiler (we don't have predicated >>>>>> value-numbering (yet)). >>>>> >>>>>> So I prefer the guard. I suppose after this discussion I prefer >>>>>> a any_dump_enabled_p () guard instead of one with (repeated) flags. >>>>> >>>>> I have updated 'dump_enabled_p ()' a little bit in >>>>> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01690.html to avoid >>>>> checking of flags. If this looks better, I can update the guard >>>>> conditions in vectorization passes from 'if (dump_kind_p (...))' to >>>>> 'if (dump_enabled_p ())'. >>>> >>>> In the patch dump_enabled_p still has an integer argument. But yes, after >>>> this discussion please make it argument-less and work towards dropping >>>> dump_kind_p (from the public interface at least). >>>> >>>> Thanks, >>>> Richard. >>>> >>>>> Thanks, >>>>> Sharad
