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,
The new dump infrastructure was committed s
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 trunk
>>> entered stage 3.
>>>
>>> However, ex
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 vectorization passes, other passes do not dump
>> anything
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 the documentation. I
> ca
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
me
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
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
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
> 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
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
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
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
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
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
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
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
> 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
Sharad Singhai schrieb:
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 different (and
hopefully cleaner) API.
Instead of this
if (dump_file)
fprint
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.
>
> thanks for the email. I hoped you'd summ
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 lost track of) led t
20 matches
Mail list logo
