Re: New dump infrastructure

2012-12-13 Thread Sharad Singhai
On Tue, Dec 11, 2012 at 1:43 AM, Richard Biener wrote: > On Mon, Dec 10, 2012 at 8:55 PM, Sharad Singhai wrote: >> On Mon, Dec 10, 2012 at 11:02 AM, Richard Biener >> wrote: >>> On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai wrote: >>>> Hi, >>>>

Re: New dump infrastructure

2012-12-11 Thread Richard Biener
On Mon, Dec 10, 2012 at 8:55 PM, Sharad Singhai wrote: > On Mon, Dec 10, 2012 at 11:02 AM, Richard Biener > wrote: >> On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai wrote: >>> Hi, >>> >>> The new dump infrastructure was committed shortly before the tru

Re: New dump infrastructure

2012-12-10 Thread Sharad Singhai
On Mon, Dec 10, 2012 at 11:02 AM, Richard Biener wrote: > On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai wrote: >> Hi, >> >> The new dump infrastructure was committed shortly before the trunk >> entered stage 3. >> >> However, except the vectori

Re: New dump infrastructure

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai 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

Re: New dump infrastructure

2012-12-10 Thread Sharad Singhai
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

Re: New dump infrastructure

2012-10-19 Thread Sharad Singhai
On Fri, Oct 19, 2012 at 12:03 PM, Xinliang David Li 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

Re: New dump infrastructure

2012-10-19 Thread Xinliang David Li
The one taking argument is changed to dump_enabled_phase (Sharad, should it be dump_enabled_phase_p ?). 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 tha

Re: New dump infrastructure

2012-10-19 Thread Richard Biener
On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai 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)). > >> S

Re: New dump infrastructure

2012-10-18 Thread Sharad Singhai
> 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 prefe

Re: New dump infrastructure

2012-10-18 Thread Xinliang David Li
sounds good. thanks, David On Thu, Oct 18, 2012 at 1:52 AM, Richard Biener wrote: > On Wed, Oct 17, 2012 at 6:55 PM, Xinliang David Li wrote: >> On Wed, Oct 17, 2012 at 2:08 AM, Richard Biener >> wrote: >>> On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li >>> wrote: A more simpler us

Re: New dump infrastructure

2012-10-18 Thread Richard Biener
On Wed, Oct 17, 2012 at 6:55 PM, Xinliang David Li wrote: > On Wed, Oct 17, 2012 at 2:08 AM, Richard Biener > wrote: >> On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li >> wrote: >>> A more simpler use model is not to guard the dump statement at all -- >>> just express the intention a) what t

Re: New dump infrastructure

2012-10-17 Thread Xinliang David Li
On Wed, Oct 17, 2012 at 1:40 PM, Sharad Singhai wrote: > On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay wrote: > >> How are dumps from the backend handled then? > > I haven't really looked at backends. Perhaps they can be converted at > the cost of extra dispatch functions defined in dumpfile

Re: New dump infrastructure

2012-10-17 Thread Sharad Singhai
On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay wrote: > How are dumps from the backend handled then? I haven't really looked at backends. Perhaps they can be converted at the cost of extra dispatch functions defined in dumpfile.c. For example, we can add methods like 'dump_rtl_single ()' and

Re: New dump infrastructure

2012-10-17 Thread Xinliang David Li
On Wed, Oct 17, 2012 at 2:08 AM, Richard Biener wrote: > On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li wrote: >> A more simpler use model is not to guard the dump statement at all -- >> just express the intention a) what to dump; b) as what kind or to >> where >> >> >> 1) I want to dump the

Re: New dump infrastructure

2012-10-17 Thread Richard Biener
On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li wrote: > A more simpler use model is not to guard the dump statement at all -- > just express the intention a) what to dump; b) as what kind or to > where > > > 1) I want to dump the something as optimized message: > > dump_printf (MSG_OPTIMIZED

Re: New dump infrastructure

2012-10-17 Thread Xinliang David Li
A more simpler use model is not to guard the dump statement at all -- just express the intention a) what to dump; b) as what kind or to where 1) I want to dump the something as optimized message: dump_printf (MSG_OPTIMIZED, "blah...") dump_printf_loc (MSG_OPTIMIZED, "blah") 2) I want to du

Re: New dump infrastructure

2012-10-16 Thread Sharad Singhai
> Indeed. I also wonder why dump_kind_p does not check if dumping is > active at all? Thus, inside check dump_file / alternate dump_file for NULL. I am testing a patch which includes a check for dump_file/alternate_dump_file in dump_kind_p. This is in addition to checking flags. >> 2. dump_kind

Fwd: New dump infrastructure

2012-10-16 Thread Sharad Singhai
> 1. OK, I understand that e.g. > > if (dump_file && (dump_flags & TDF_DETAILS)) > >should be converted into: > > if (dump_kind_p (TDF_DETAILS)) > >But what about current code that does not care about dump_flags? >E.g. converting simple > > if (dump_file) > >to > >

Re: New dump infrastructure

2012-10-16 Thread Georg-Johann Lay
) fprintf (dump_file, ...); the new style looks like this if (dump_kind_p (...)) dump_printf (...) [...] Since the number of existing dump call sites is quite large, currently both old *and* new schemes are in use. The plan is to gradually transition passes to use the new dump infrastructure

Re: New dump infrastructure

2012-10-16 Thread Richard Biener
On Tue, Oct 16, 2012 at 3:41 PM, Martin Jambor wrote: > Hi, > > On Tue, Oct 16, 2012 at 01:21:29AM -0700, Sharad Singhai wrote: >> Hi, >> >> This is a solicitation for help in converting passes to use the new >> dump infrastructure. More context below. > &g

Re: New dump infrastructure

2012-10-16 Thread Martin Jambor
Hi, On Tue, Oct 16, 2012 at 01:21:29AM -0700, Sharad Singhai wrote: > Hi, > > This is a solicitation for help in converting passes to use the new > dump infrastructure. More context below. thanks for the email. I hoped you'd summarize what the long thread about this (that I l

New dump infrastructure

2012-10-16 Thread Sharad Singhai
Hi, This is a solicitation for help in converting passes to use the new dump infrastructure. More context below. I have enhanced the dump infrastructure in r191883, r191884. These patches updated the tree/rtl dump facility so that passes do not reference the dump file directly, but instead use a