* Dump file usage patterns?
@ 2010-08-25 11:12 Bernd Schmidt
2010-08-25 12:22 ` Richard Guenther
2010-08-25 12:50 ` Jakub Jelinek
0 siblings, 2 replies; 5+ messages in thread
From: Bernd Schmidt @ 2010-08-25 11:12 UTC (permalink / raw)
To: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
How are people using dump files? I find myself adding -fdump-noaddr to
every command line with -da, as I often run diff on dumps from two
different compilers. How about the patch below? Should we print cselib
information only when given a specific flag - I don't find it very
useful and it clutters up the dump files?
Bernd
[-- Attachment #2: noaddr.diff --]
[-- Type: text/plain, Size: 459 bytes --]
Index: common.opt
===================================================================
--- common.opt (revision 162821)
+++ common.opt (working copy)
@@ -493,7 +493,7 @@ Common RejectNegative Joined Var(flag_du
-fdump-final-insns=filename Dump to filename the insns at the end of translation
fdump-noaddr
-Common Report Var(flag_dump_noaddr)
+Common Report Var(flag_dump_noaddr) Init(1)
Suppress output of addresses in debugging dumps
fdump-unnumbered
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Dump file usage patterns?
2010-08-25 11:12 Dump file usage patterns? Bernd Schmidt
@ 2010-08-25 12:22 ` Richard Guenther
2010-08-25 12:50 ` Jakub Jelinek
1 sibling, 0 replies; 5+ messages in thread
From: Richard Guenther @ 2010-08-25 12:22 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: GCC Patches
On Wed, Aug 25, 2010 at 12:55 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> How are people using dump files? I find myself adding -fdump-noaddr to
> every command line with -da, as I often run diff on dumps from two
> different compilers. How about the patch below? Should we print cselib
> information only when given a specific flag - I don't find it very
> useful and it clutters up the dump files?
With the patch the naming of the option doesn't make much sense.
The flag is also not used too often - maybe it's more useful to
dump UIDs than addresses, for example from DF.
Your suggestion about cselib info is good.
Richard.
>
> Bernd
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Dump file usage patterns?
2010-08-25 11:12 Dump file usage patterns? Bernd Schmidt
2010-08-25 12:22 ` Richard Guenther
@ 2010-08-25 12:50 ` Jakub Jelinek
2011-01-28 16:46 ` Bernd Schmidt
1 sibling, 1 reply; 5+ messages in thread
From: Jakub Jelinek @ 2010-08-25 12:50 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: GCC Patches
On Wed, Aug 25, 2010 at 12:55:07PM +0200, Bernd Schmidt wrote:
> Should we print cselib
> information only when given a specific flag - I don't find it very
> useful and it clutters up the dump files?
For var-tracking issues it is very useful, but I guess I don't mind enabling
it with an extra option.
Jakub
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Dump file usage patterns?
2010-08-25 12:50 ` Jakub Jelinek
@ 2011-01-28 16:46 ` Bernd Schmidt
2011-01-28 16:52 ` Richard Guenther
0 siblings, 1 reply; 5+ messages in thread
From: Bernd Schmidt @ 2011-01-28 16:46 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
On 08/25/2010 01:17 PM, Jakub Jelinek wrote:
> On Wed, Aug 25, 2010 at 12:55:07PM +0200, Bernd Schmidt wrote:
>> Should we print cselib
>> information only when given a specific flag - I don't find it very
>> useful and it clutters up the dump files?
>
> For var-tracking issues it is very useful, but I guess I don't mind enabling
> it with an extra option.
How's this? Bootstrapped and tested on i686-linux.
Bernd
[-- Attachment #2: dump-cselib.diff --]
[-- Type: text/plain, Size: 3378 bytes --]
* tree-dump.c (dump_option_value_info): Add entry for TDF_CSELIB.
* tree-pass.h (TDF_CSELIB): New macro.
* cselib.c (new_cselib_val, expand_loc, cselib_expand_value_rtx_1,
cselib_lookup): Check for it rather than for TDF_DETAILS.
Index: tree-dump.c
===================================================================
--- tree-dump.c (revision 169334)
+++ tree-dump.c (working copy)
@@ -814,6 +814,7 @@ static const struct dump_option_value_in
{"raw", TDF_RAW},
{"graph", TDF_GRAPH},
{"details", TDF_DETAILS},
+ {"cselib", TDF_CSELIB},
{"stats", TDF_STATS},
{"blocks", TDF_BLOCKS},
{"vops", TDF_VOPS},
Index: tree-pass.h
===================================================================
--- tree-pass.h (revision 169334)
+++ tree-pass.h (working copy)
@@ -82,6 +82,7 @@ enum tree_dump_index
#define TDF_NOUID (1 << 20) /* omit UIDs from dumps. */
#define TDF_ALIAS (1 << 21) /* display alias information */
#define TDF_ENUMERATE_LOCALS (1 << 22) /* Enumerate locals by uid. */
+#define TDF_CSELIB (1 << 23) /* Dump cselib details. */
/* In tree-dump.c */
Index: cselib.c
===================================================================
--- cselib.c (revision 169334)
+++ cselib.c (working copy)
@@ -1015,7 +1015,7 @@ new_cselib_val (unsigned int hash, enum
e->locs = 0;
e->next_containing_mem = 0;
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
{
fprintf (dump_file, "cselib value %u:%u ", e->uid, hash);
if (flag_dump_noaddr || flag_dump_unnumbered)
@@ -1132,7 +1132,7 @@ expand_loc (struct elt_loc_list *p, stru
else if (!REG_P (p->loc))
{
rtx result, note;
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
{
print_inline_rtx (dump_file, p->loc, 0);
fprintf (dump_file, "\n");
@@ -1153,7 +1153,7 @@ expand_loc (struct elt_loc_list *p, stru
if (regno != UINT_MAX)
{
rtx result;
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
fprintf (dump_file, "r%d\n", regno);
result = cselib_expand_value_rtx_1 (reg_result, evd, max_depth - 1);
@@ -1161,7 +1161,7 @@ expand_loc (struct elt_loc_list *p, stru
return result;
}
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
{
if (reg_result)
{
@@ -1302,7 +1302,7 @@ cselib_expand_value_rtx_1 (rtx orig, str
bitmap_set_bit (evd->regs_active, regno);
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
fprintf (dump_file, "expanding: r%d into: ", regno);
result = expand_loc (l->elt->locs, evd, max_depth);
@@ -1367,7 +1367,7 @@ cselib_expand_value_rtx_1 (rtx orig, str
{
rtx result;
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
{
fputs ("\nexpanding ", dump_file);
print_rtl_single (dump_file, orig);
@@ -1736,7 +1736,7 @@ cselib_lookup (rtx x, enum machine_mode
easiest setting cselib_current_insn to NULL before the call
above. */
- if (dump_file && (dump_flags & TDF_DETAILS))
+ if (dump_file && (dump_flags & TDF_CSELIB))
{
fputs ("cselib lookup ", dump_file);
print_inline_rtx (dump_file, x, 2);
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Dump file usage patterns?
2011-01-28 16:46 ` Bernd Schmidt
@ 2011-01-28 16:52 ` Richard Guenther
0 siblings, 0 replies; 5+ messages in thread
From: Richard Guenther @ 2011-01-28 16:52 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: Jakub Jelinek, GCC Patches
On Fri, Jan 28, 2011 at 5:12 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 08/25/2010 01:17 PM, Jakub Jelinek wrote:
>> On Wed, Aug 25, 2010 at 12:55:07PM +0200, Bernd Schmidt wrote:
>>> Should we print cselib
>>> information only when given a specific flag - I don't find it very
>>> useful and it clutters up the dump files?
>>
>> For var-tracking issues it is very useful, but I guess I don't mind enabling
>> it with an extra option.
>
> How's this? Bootstrapped and tested on i686-linux.
Looks good to me.
Richard.
>
> Bernd
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-01-28 16:29 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-25 11:12 Dump file usage patterns? Bernd Schmidt
2010-08-25 12:22 ` Richard Guenther
2010-08-25 12:50 ` Jakub Jelinek
2011-01-28 16:46 ` Bernd Schmidt
2011-01-28 16:52 ` Richard Guenther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).