| Message ID | 1530030410-22772-1-git-send-email-dmalcolm@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | -fopt-info: add indentation via DUMP_VECT_SCOPE | expand |
On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat.com> wrote: > > This patch adds a concept of nested "scopes" to dumpfile.c's dump_*_loc > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree-vectorizer.h, > so that the nested structure is shown in -fopt-info by indentation. > > For example, this converts -fopt-info-all e.g. from: > > test.c:8:3: note: === analyzing loop === > test.c:8:3: note: === analyze_loop_nest === > test.c:8:3: note: === vect_analyze_loop_form === > test.c:8:3: note: === get_loop_niters === > test.c:8:3: note: symbolic number of iterations is (unsigned int) n_9(D) > test.c:8:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed > test.c:8:3: note: vectorized 0 loops in function > > to: > > test.c:8:3: note: === analyzing loop === > test.c:8:3: note: === analyze_loop_nest === > test.c:8:3: note: === vect_analyze_loop_form === > test.c:8:3: note: === get_loop_niters === > test.c:8:3: note: symbolic number of iterations is (unsigned int) n_9(D) > test.c:8:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed > test.c:8:3: note: vectorized 0 loops in function > > showing that the "symbolic number of iterations" message is within > the "=== analyze_loop_nest ===" (and not within the > "=== vect_analyze_loop_form ==="). > > This is also enabling work for followups involving optimization records > (allowing the records to directly capture the nested structure of the > dump messages). > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > OK for trunk? OK and sorry for the delay. Richard. > gcc/ChangeLog: > * dumpfile.c (dump_loc): Add indentation based on scope depth. > (dump_scope_depth): New variable. > (get_dump_scope_depth): New function. > (dump_begin_scope): New function. > (dump_end_scope): New function. > * dumpfile.h (get_dump_scope_depth): New declaration. > (dump_begin_scope): New declaration. > (dump_end_scope): New declaration. > (class auto_dump_scope): New class. > (AUTO_DUMP_SCOPE): New macro. > * tree-vectorizer.h (DUMP_VECT_SCOPE): Reimplement in terms of > AUTO_DUMP_SCOPE. > --- > gcc/dumpfile.c | 35 +++++++++++++++++++++++++++++++++++ > gcc/dumpfile.h | 39 +++++++++++++++++++++++++++++++++++++++ > gcc/tree-vectorizer.h | 15 ++++++++------- > 3 files changed, 82 insertions(+), 7 deletions(-) > > diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c > index 122e420..190b52d 100644 > --- a/gcc/dumpfile.c > +++ b/gcc/dumpfile.c > @@ -419,6 +419,8 @@ dump_loc (dump_flags_t dump_kind, FILE *dfile, source_location loc) > DECL_SOURCE_FILE (current_function_decl), > DECL_SOURCE_LINE (current_function_decl), > DECL_SOURCE_COLUMN (current_function_decl)); > + /* Indentation based on scope depth. */ > + fprintf (dfile, "%*s", get_dump_scope_depth (), ""); > } > } > > @@ -539,6 +541,39 @@ template void dump_dec (dump_flags_t, const poly_uint64 &); > template void dump_dec (dump_flags_t, const poly_offset_int &); > template void dump_dec (dump_flags_t, const poly_widest_int &); > > +/* The current dump scope-nesting depth. */ > + > +static int dump_scope_depth; > + > +/* Get the current dump scope-nesting depth. > + For use by dump_*_loc (for showing nesting via indentation). */ > + > +unsigned int > +get_dump_scope_depth () > +{ > + return dump_scope_depth; > +} > + > +/* Push a nested dump scope. > + Print "=== NAME ===\n" to the dumpfile, if any, and to the -fopt-info > + destination, if any. > + Increment the scope depth. */ > + > +void > +dump_begin_scope (const char *name, const dump_location_t &loc) > +{ > + dump_printf_loc (MSG_NOTE, loc, "=== %s ===\n", name); > + dump_scope_depth++; > +} > + > +/* Pop a nested dump scope. */ > + > +void > +dump_end_scope () > +{ > + dump_scope_depth--; > +} > + > /* Start a dump for PHASE. Store user-supplied dump flags in > *FLAG_PTR. Return the number of streams opened. Set globals > DUMP_FILE, and ALT_DUMP_FILE to point to the opened streams, and > diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h > index 90d8930..89d5c11 100644 > --- a/gcc/dumpfile.h > +++ b/gcc/dumpfile.h > @@ -456,6 +456,45 @@ dump_enabled_p (void) > return (dump_file || alt_dump_file); > } > > +/* Managing nested scopes, so that dumps can express the call chain > + leading to a dump message. */ > + > +extern unsigned int get_dump_scope_depth (); > +extern void dump_begin_scope (const char *name, const dump_location_t &loc); > +extern void dump_end_scope (); > + > +/* Implementation detail of the AUTO_DUMP_SCOPE macro below. > + > + A RAII-style class intended to make it easy to emit dump > + information about entering and exiting a collection of nested > + function calls. */ > + > +class auto_dump_scope > +{ > + public: > + auto_dump_scope (const char *name, dump_location_t loc) > + { > + if (dump_enabled_p ()) > + dump_begin_scope (name, loc); > + } > + ~auto_dump_scope () > + { > + if (dump_enabled_p ()) > + dump_end_scope (); > + } > +}; > + > +/* A macro for calling: > + dump_begin_scope (NAME, LOC); > + via an RAII object, thus printing "=== MSG ===\n" to the dumpfile etc, > + and then calling > + dump_end_scope (); > + once the object goes out of scope, thus capturing the nesting of > + the scopes. */ > + > +#define AUTO_DUMP_SCOPE(NAME, LOC) \ > + auto_dump_scope scope (NAME, LOC) > + > namespace gcc { > > class dump_manager > diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h > index 94a0f38..a8406b3 100644 > --- a/gcc/tree-vectorizer.h > +++ b/gcc/tree-vectorizer.h > @@ -1440,15 +1440,16 @@ vect_get_scalar_dr_size (struct data_reference *dr) > /* Source location + hotness information. */ > extern dump_user_location_t vect_location; > > -/* If dumping is enabled, emit a MSG_NOTE at vect_location about > - entering MSG within the vectorizer. MSG should be a string literal. */ > +/* A macro for calling: > + dump_begin_scope (MSG, vect_location); > + via an RAII object, thus printing "=== MSG ===\n" to the dumpfile etc, > + and then calling > + dump_end_scope (); > + once the object goes out of scope, thus capturing the nesting of > + the scopes. */ > > #define DUMP_VECT_SCOPE(MSG) \ > - do { \ > - if (dump_enabled_p ()) \ > - dump_printf_loc (MSG_NOTE, vect_location, \ > - "=== " MSG " ===\n"); \ > - } while (0) > + AUTO_DUMP_SCOPE (MSG, vect_location) > > /*-----------------------------------------------------------------*/ > /* Function prototypes. */ > -- > 1.8.5.3 >
On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gmail.com> wrote: > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat.com> wrote: > > > > This patch adds a concept of nested "scopes" to dumpfile.c's dump_*_loc > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree-vectorizer.h, > > so that the nested structure is shown in -fopt-info by indentation. > > > > For example, this converts -fopt-info-all e.g. from: > > > > test.c:8:3: note: === analyzing loop === > > test.c:8:3: note: === analyze_loop_nest === > > test.c:8:3: note: === vect_analyze_loop_form === > > test.c:8:3: note: === get_loop_niters === > > test.c:8:3: note: symbolic number of iterations is (unsigned int) n_9(D) > > test.c:8:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed > > test.c:8:3: note: vectorized 0 loops in function > > > > to: > > > > test.c:8:3: note: === analyzing loop === > > test.c:8:3: note: === analyze_loop_nest === > > test.c:8:3: note: === vect_analyze_loop_form === > > test.c:8:3: note: === get_loop_niters === > > test.c:8:3: note: symbolic number of iterations is (unsigned int) n_9(D) > > test.c:8:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed > > test.c:8:3: note: vectorized 0 loops in function > > > > showing that the "symbolic number of iterations" message is within > > the "=== analyze_loop_nest ===" (and not within the > > "=== vect_analyze_loop_form ==="). > > > > This is also enabling work for followups involving optimization records > > (allowing the records to directly capture the nested structure of the > > dump messages). > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > OK for trunk? > Hi, I've noticed that this patch (r262246) caused regressions on aarch64: gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP cancelled: can use load/store-lanes" The problem is that now there are more spaces between "note:" and "Built", the attached small patch does that for slp-perm-1.c. Is it the right way of fixing it or do we want to accept any amount of spaces for instance? I'm surprised there is such little impact on the testsuite though. If OK, I'll update the patch to take the other slp-perm-[235678].c tests into account. Thanks, Christophe > OK and sorry for the delay. > Richard. > > > gcc/ChangeLog: > > * dumpfile.c (dump_loc): Add indentation based on scope depth. > > (dump_scope_depth): New variable. > > (get_dump_scope_depth): New function. > > (dump_begin_scope): New function. > > (dump_end_scope): New function. > > * dumpfile.h (get_dump_scope_depth): New declaration. > > (dump_begin_scope): New declaration. > > (dump_end_scope): New declaration. > > (class auto_dump_scope): New class. > > (AUTO_DUMP_SCOPE): New macro. > > * tree-vectorizer.h (DUMP_VECT_SCOPE): Reimplement in terms of > > AUTO_DUMP_SCOPE. > > --- > > gcc/dumpfile.c | 35 +++++++++++++++++++++++++++++++++++ > > gcc/dumpfile.h | 39 +++++++++++++++++++++++++++++++++++++++ > > gcc/tree-vectorizer.h | 15 ++++++++------- > > 3 files changed, 82 insertions(+), 7 deletions(-) > > > > diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c > > index 122e420..190b52d 100644 > > --- a/gcc/dumpfile.c > > +++ b/gcc/dumpfile.c > > @@ -419,6 +419,8 @@ dump_loc (dump_flags_t dump_kind, FILE *dfile, source_location loc) > > DECL_SOURCE_FILE (current_function_decl), > > DECL_SOURCE_LINE (current_function_decl), > > DECL_SOURCE_COLUMN (current_function_decl)); > > + /* Indentation based on scope depth. */ > > + fprintf (dfile, "%*s", get_dump_scope_depth (), ""); > > } > > } > > > > @@ -539,6 +541,39 @@ template void dump_dec (dump_flags_t, const poly_uint64 &); > > template void dump_dec (dump_flags_t, const poly_offset_int &); > > template void dump_dec (dump_flags_t, const poly_widest_int &); > > > > +/* The current dump scope-nesting depth. */ > > + > > +static int dump_scope_depth; > > + > > +/* Get the current dump scope-nesting depth. > > + For use by dump_*_loc (for showing nesting via indentation). */ > > + > > +unsigned int > > +get_dump_scope_depth () > > +{ > > + return dump_scope_depth; > > +} > > + > > +/* Push a nested dump scope. > > + Print "=== NAME ===\n" to the dumpfile, if any, and to the -fopt-info > > + destination, if any. > > + Increment the scope depth. */ > > + > > +void > > +dump_begin_scope (const char *name, const dump_location_t &loc) > > +{ > > + dump_printf_loc (MSG_NOTE, loc, "=== %s ===\n", name); > > + dump_scope_depth++; > > +} > > + > > +/* Pop a nested dump scope. */ > > + > > +void > > +dump_end_scope () > > +{ > > + dump_scope_depth--; > > +} > > + > > /* Start a dump for PHASE. Store user-supplied dump flags in > > *FLAG_PTR. Return the number of streams opened. Set globals > > DUMP_FILE, and ALT_DUMP_FILE to point to the opened streams, and > > diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h > > index 90d8930..89d5c11 100644 > > --- a/gcc/dumpfile.h > > +++ b/gcc/dumpfile.h > > @@ -456,6 +456,45 @@ dump_enabled_p (void) > > return (dump_file || alt_dump_file); > > } > > > > +/* Managing nested scopes, so that dumps can express the call chain > > + leading to a dump message. */ > > + > > +extern unsigned int get_dump_scope_depth (); > > +extern void dump_begin_scope (const char *name, const dump_location_t &loc); > > +extern void dump_end_scope (); > > + > > +/* Implementation detail of the AUTO_DUMP_SCOPE macro below. > > + > > + A RAII-style class intended to make it easy to emit dump > > + information about entering and exiting a collection of nested > > + function calls. */ > > + > > +class auto_dump_scope > > +{ > > + public: > > + auto_dump_scope (const char *name, dump_location_t loc) > > + { > > + if (dump_enabled_p ()) > > + dump_begin_scope (name, loc); > > + } > > + ~auto_dump_scope () > > + { > > + if (dump_enabled_p ()) > > + dump_end_scope (); > > + } > > +}; > > + > > +/* A macro for calling: > > + dump_begin_scope (NAME, LOC); > > + via an RAII object, thus printing "=== MSG ===\n" to the dumpfile etc, > > + and then calling > > + dump_end_scope (); > > + once the object goes out of scope, thus capturing the nesting of > > + the scopes. */ > > + > > +#define AUTO_DUMP_SCOPE(NAME, LOC) \ > > + auto_dump_scope scope (NAME, LOC) > > + > > namespace gcc { > > > > class dump_manager > > diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h > > index 94a0f38..a8406b3 100644 > > --- a/gcc/tree-vectorizer.h > > +++ b/gcc/tree-vectorizer.h > > @@ -1440,15 +1440,16 @@ vect_get_scalar_dr_size (struct data_reference *dr) > > /* Source location + hotness information. */ > > extern dump_user_location_t vect_location; > > > > -/* If dumping is enabled, emit a MSG_NOTE at vect_location about > > - entering MSG within the vectorizer. MSG should be a string literal. */ > > +/* A macro for calling: > > + dump_begin_scope (MSG, vect_location); > > + via an RAII object, thus printing "=== MSG ===\n" to the dumpfile etc, > > + and then calling > > + dump_end_scope (); > > + once the object goes out of scope, thus capturing the nesting of > > + the scopes. */ > > > > #define DUMP_VECT_SCOPE(MSG) \ > > - do { \ > > - if (dump_enabled_p ()) \ > > - dump_printf_loc (MSG_NOTE, vect_location, \ > > - "=== " MSG " ===\n"); \ > > - } while (0) > > + AUTO_DUMP_SCOPE (MSG, vect_location) > > > > /*-----------------------------------------------------------------*/ > > /* Function prototypes. */ > > -- > > 1.8.5.3 > > gcc/testsuite/ChangeLog: 2018-07-02 Christophe Lyon <christophe.lyon@linaro.org> * gcc.dg/vect/slp-perm-1.c: Adjust scan-tree-dump directive after new indentation. diff --git a/gcc/testsuite/gcc.dg/vect/slp-perm-1.c b/gcc/testsuite/gcc.dg/vect/slp-perm-1.c index 6bd16ef..612139ba 100644 --- a/gcc/testsuite/gcc.dg/vect/slp-perm-1.c +++ b/gcc/testsuite/gcc.dg/vect/slp-perm-1.c @@ -82,7 +82,7 @@ int main (int argc, const char* argv[]) /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target vect_perm } } } */ /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" { target { vect_perm3_int && {! vect_load_lanes } } } } } */ /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" { target vect_load_lanes } } } */ -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ +/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ /* { dg-final { scan-tree-dump "LOAD_LANES" "vect" { target vect_load_lanes } } } */ /* { dg-final { scan-tree-dump "STORE_LANES" "vect" { target vect_load_lanes } } } */
On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gmail. > com> wrote: > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat.com> > > wrote: > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > dump_*_loc > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > vectorizer.h, > > > so that the nested structure is shown in -fopt-info by > > > indentation. > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > test.c:8:3: note: === analyzing loop === > > > test.c:8:3: note: === analyze_loop_nest === > > > test.c:8:3: note: === vect_analyze_loop_form === > > > test.c:8:3: note: === get_loop_niters === > > > test.c:8:3: note: symbolic number of iterations is (unsigned int) > > > n_9(D) > > > test.c:8:3: note: not vectorized: loop contains function calls or > > > data references that cannot be analyzed > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > to: > > > > > > test.c:8:3: note: === analyzing loop === > > > test.c:8:3: note: === analyze_loop_nest === > > > test.c:8:3: note: === vect_analyze_loop_form === > > > test.c:8:3: note: === get_loop_niters === > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > int) n_9(D) > > > test.c:8:3: note: not vectorized: loop contains function calls > > > or data references that cannot be analyzed > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > showing that the "symbolic number of iterations" message is > > > within > > > the "=== analyze_loop_nest ===" (and not within the > > > "=== vect_analyze_loop_form ==="). > > > > > > This is also enabling work for followups involving optimization > > > records > > > (allowing the records to directly capture the nested structure of > > > the > > > dump messages). > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > > > OK for trunk? > > Hi, > > I've noticed that this patch (r262246) caused regressions on aarch64: > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree-dump > vect "note: Built SLP cancelled: can use load/store-lanes" > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > cancelled: can use load/store-lanes" > > The problem is that now there are more spaces between "note:" and > "Built", the attached small patch does that for slp-perm-1.c. Sorry about the breakage. > Is it the right way of fixing it or do we want to accept any amount > of > spaces for instance? I don't think we want to hardcode the amount of space in the dumpfile. The idea of my patch was to make the dump more human-readable (I hope) by visualizing the nesting structure of the dump messages, but I think we shouldn't "bake" that into the expected strings, as someone might want to add an intermediate nesting level. Do we really need to look for the "note:" in the scan-tree-dump? Should that directive be rewritten to: -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ which I believe would match any amount of spaces. Alternatively a regex accepting any amount of space ought to work, if we care that the message begins with "note: ". The "note: " comes from dumpfile.c's dump_loc, and is emitted regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION or whatever. Given that, maybe we should just drop the "note: " prefix from these scan-tree-dump expected regexes? (assuming that works) > I'm surprised there is such little impact on the testsuite though. I see lots of scan-tree-dump* directives in the vect part of the testsuite, but it seems that only these ones use the "note: " prefix; I think everything else was matching against the message whilst ignoring the prefix, so it didn't matter when the prefix changed (I double-checked and these scan-tree-dump directives didn't trigger on my x86_64 testing of the patch, due to { target { vect_perm3_int && vect_load_lanes } }, where I see check_effective_target_vect_load_lanes: returning 0 in the log) > If OK, I'll update the patch to take the other slp-perm-[235678].c > tests into account. > > Thanks, > > Christophe Sorry again about the breakage. Dave
On Mon, 2 Jul 2018 at 19:00, David Malcolm <dmalcolm@redhat.com> wrote: > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gmail. > > com> wrote: > > > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat.com> > > > wrote: > > > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > > dump_*_loc > > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > > vectorizer.h, > > > > so that the nested structure is shown in -fopt-info by > > > > indentation. > > > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > test.c:8:3: note: === analyze_loop_nest === > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > test.c:8:3: note: === get_loop_niters === > > > > test.c:8:3: note: symbolic number of iterations is (unsigned int) > > > > n_9(D) > > > > test.c:8:3: note: not vectorized: loop contains function calls or > > > > data references that cannot be analyzed > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > to: > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > test.c:8:3: note: === analyze_loop_nest === > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > test.c:8:3: note: === get_loop_niters === > > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > > int) n_9(D) > > > > test.c:8:3: note: not vectorized: loop contains function calls > > > > or data references that cannot be analyzed > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > showing that the "symbolic number of iterations" message is > > > > within > > > > the "=== analyze_loop_nest ===" (and not within the > > > > "=== vect_analyze_loop_form ==="). > > > > > > > > This is also enabling work for followups involving optimization > > > > records > > > > (allowing the records to directly capture the nested structure of > > > > the > > > > dump messages). > > > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > > > > > OK for trunk? > > > > Hi, > > > > I've noticed that this patch (r262246) caused regressions on aarch64: > > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > > > The problem is that now there are more spaces between "note:" and > > "Built", the attached small patch does that for slp-perm-1.c. > > Sorry about the breakage. > > > Is it the right way of fixing it or do we want to accept any amount > > of > > spaces for instance? > > I don't think we want to hardcode the amount of space in the dumpfile. > The idea of my patch was to make the dump more human-readable (I hope) > by visualizing the nesting structure of the dump messages, but I think > we shouldn't "bake" that into the expected strings, as someone might > want to add an intermediate nesting level. > > Do we really need to look for the "note:" in the scan-tree-dump? > Should that directive be rewritten to: > > -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ > +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ > > which I believe would match any amount of spaces. I thought about that too, and like you noticed that almost all other scan-tree-dump directives omitted the "note:" part. It seems like a better approach, unless someone objects? > > Alternatively a regex accepting any amount of space ought to work, if > we care that the message begins with "note: ". > > The "note: " comes from dumpfile.c's dump_loc, and is emitted > regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION or > whatever. Given that, maybe we should just drop the "note: " prefix > from these scan-tree-dump expected regexes? (assuming that works) > > > I'm surprised there is such little impact on the testsuite though. > > I see lots of scan-tree-dump* directives in the vect part of the > testsuite, but it seems that only these ones use the "note: " prefix; I > think everything else was matching against the message whilst ignoring > the prefix, so it didn't matter when the prefix changed > (I double-checked and these scan-tree-dump directives didn't trigger on > my x86_64 testing of the patch, due to { target { vect_perm3_int && > vect_load_lanes } }, where I see > check_effective_target_vect_load_lanes: returning 0 in the log) > > > If OK, I'll update the patch to take the other slp-perm-[235678].c > > tests into account. > > > > Thanks, > > > > Christophe > > Sorry again about the breakage. > Dave >
On Mon, Jul 2, 2018 at 7:00 PM David Malcolm <dmalcolm@redhat.com> wrote: > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gmail. > > com> wrote: > > > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat.com> > > > wrote: > > > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > > dump_*_loc > > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > > vectorizer.h, > > > > so that the nested structure is shown in -fopt-info by > > > > indentation. > > > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > test.c:8:3: note: === analyze_loop_nest === > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > test.c:8:3: note: === get_loop_niters === > > > > test.c:8:3: note: symbolic number of iterations is (unsigned int) > > > > n_9(D) > > > > test.c:8:3: note: not vectorized: loop contains function calls or > > > > data references that cannot be analyzed > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > to: > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > test.c:8:3: note: === analyze_loop_nest === > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > test.c:8:3: note: === get_loop_niters === > > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > > int) n_9(D) > > > > test.c:8:3: note: not vectorized: loop contains function calls > > > > or data references that cannot be analyzed > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > showing that the "symbolic number of iterations" message is > > > > within > > > > the "=== analyze_loop_nest ===" (and not within the > > > > "=== vect_analyze_loop_form ==="). > > > > > > > > This is also enabling work for followups involving optimization > > > > records > > > > (allowing the records to directly capture the nested structure of > > > > the > > > > dump messages). > > > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > > > > > OK for trunk? > > > > Hi, > > > > I've noticed that this patch (r262246) caused regressions on aarch64: > > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree-dump > > vect "note: Built SLP cancelled: can use load/store-lanes" > > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > > cancelled: can use load/store-lanes" > > > > The problem is that now there are more spaces between "note:" and > > "Built", the attached small patch does that for slp-perm-1.c. > > Sorry about the breakage. > > > Is it the right way of fixing it or do we want to accept any amount > > of > > spaces for instance? > > I don't think we want to hardcode the amount of space in the dumpfile. > The idea of my patch was to make the dump more human-readable (I hope) > by visualizing the nesting structure of the dump messages, but I think > we shouldn't "bake" that into the expected strings, as someone might > want to add an intermediate nesting level. > > Do we really need to look for the "note:" in the scan-tree-dump? > Should that directive be rewritten to: > > -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ > +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use load/store-lanes" "vect" { target { vect_perm3_int && vect_load_lanes } } } } */ > > which I believe would match any amount of spaces. > > Alternatively a regex accepting any amount of space ought to work, if > we care that the message begins with "note: ". > > The "note: " comes from dumpfile.c's dump_loc, and is emitted > regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION or > whatever. Given that, maybe we should just drop the "note: " prefix > from these scan-tree-dump expected regexes? (assuming that works) I guess it was done for the -fopt-info output channel to match what we emit with inform () given those are neither warnings nor errors. But yes, lets elide "note: " from dumpfiles. Be prepared to fiddle with expected scan-dumps though. > > I'm surprised there is such little impact on the testsuite though. > > I see lots of scan-tree-dump* directives in the vect part of the > testsuite, but it seems that only these ones use the "note: " prefix; I > think everything else was matching against the message whilst ignoring > the prefix, so it didn't matter when the prefix changed > (I double-checked and these scan-tree-dump directives didn't trigger on > my x86_64 testing of the patch, due to { target { vect_perm3_int && > vect_load_lanes } }, where I see > check_effective_target_vect_load_lanes: returning 0 in the log) > > > If OK, I'll update the patch to take the other slp-perm-[235678].c > > tests into account. > > > > Thanks, > > > > Christophe > > Sorry again about the breakage. > Dave >
On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote: > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm <dmalcolm@redhat.com> > wrote: > > > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > > > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gm > > > ail. > > > com> wrote: > > > > > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat. > > > > com> > > > > wrote: > > > > > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > > > dump_*_loc > > > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > > > vectorizer.h, > > > > > so that the nested structure is shown in -fopt-info by > > > > > indentation. > > > > > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > test.c:8:3: note: === get_loop_niters === > > > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > > > int) > > > > > n_9(D) > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > calls or > > > > > data references that cannot be analyzed > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > to: > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > test.c:8:3: note: === get_loop_niters === > > > > > test.c:8:3: note: symbolic number of iterations is > > > > > (unsigned > > > > > int) n_9(D) > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > calls > > > > > or data references that cannot be analyzed > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > showing that the "symbolic number of iterations" message is > > > > > within > > > > > the "=== analyze_loop_nest ===" (and not within the > > > > > "=== vect_analyze_loop_form ==="). > > > > > > > > > > This is also enabling work for followups involving > > > > > optimization > > > > > records > > > > > (allowing the records to directly capture the nested > > > > > structure of > > > > > the > > > > > dump messages). > > > > > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux- > > > > > gnu. > > > > > > > > > > OK for trunk? > > > > > > Hi, > > > > > > I've noticed that this patch (r262246) caused regressions on > > > aarch64: > > > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree- > > > dump > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > > > cancelled: can use load/store-lanes" > > > > > > The problem is that now there are more spaces between "note:" and > > > "Built", the attached small patch does that for slp-perm-1.c. > > > > Sorry about the breakage. > > > > > Is it the right way of fixing it or do we want to accept any > > > amount > > > of > > > spaces for instance? > > > > I don't think we want to hardcode the amount of space in the > > dumpfile. > > The idea of my patch was to make the dump more human-readable (I > > hope) > > by visualizing the nesting structure of the dump messages, but I > > think > > we shouldn't "bake" that into the expected strings, as someone > > might > > want to add an intermediate nesting level. > > > > Do we really need to look for the "note:" in the scan-tree-dump? > > Should that directive be rewritten to: > > > > -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use > > load/store-lanes" "vect" { target { vect_perm3_int && > > vect_load_lanes } } } } */ > > +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use > > load/store-lanes" "vect" { target { vect_perm3_int && > > vect_load_lanes } } } } */ > > > > which I believe would match any amount of spaces. > > > > Alternatively a regex accepting any amount of space ought to work, > > if > > we care that the message begins with "note: ". > > > > The "note: " comes from dumpfile.c's dump_loc, and is emitted > > regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION > > or > > whatever. Given that, maybe we should just drop the "note: " > > prefix > > from these scan-tree-dump expected regexes? (assuming that works) > > I guess it was done for the -fopt-info output channel to match what > we emit with inform () given those are neither warnings nor errors. > > But yes, lets elide "note: " from dumpfiles. Be prepared to fiddle > with expected scan-dumps though. Re-reading, I think I was unclear, but I was proposing removing it from the scan-tree-dump regexes, *not* from dumpfile.c (though I'm open to the latter). > > > > I'm surprised there is such little impact on the testsuite > > > though. > > > > I see lots of scan-tree-dump* directives in the vect part of the > > testsuite, but it seems that only these ones use the "note: " > > prefix; I > > think everything else was matching against the message whilst > > ignoring > > the prefix, so it didn't matter when the prefix changed > > (I double-checked and these scan-tree-dump directives didn't > > trigger on > > my x86_64 testing of the patch, due to { target { vect_perm3_int && > > vect_load_lanes } }, where I see > > check_effective_target_vect_load_lanes: returning 0 in the log) > > > > > If OK, I'll update the patch to take the other slp-perm- > > > [235678].c > > > tests into account. > > > > > > Thanks, > > > > > > Christophe > > > > Sorry again about the breakage. > > Dave > >
On Tue, Jul 3, 2018 at 3:52 PM David Malcolm <dmalcolm@redhat.com> wrote: > > On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote: > > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm <dmalcolm@redhat.com> > > wrote: > > > > > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > > > > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gm > > > > ail. > > > > com> wrote: > > > > > > > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat. > > > > > com> > > > > > wrote: > > > > > > > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > > > > dump_*_loc > > > > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > > > > vectorizer.h, > > > > > > so that the nested structure is shown in -fopt-info by > > > > > > indentation. > > > > > > > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > > test.c:8:3: note: === get_loop_niters === > > > > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > > > > int) > > > > > > n_9(D) > > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > > calls or > > > > > > data references that cannot be analyzed > > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > > > to: > > > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > > test.c:8:3: note: === get_loop_niters === > > > > > > test.c:8:3: note: symbolic number of iterations is > > > > > > (unsigned > > > > > > int) n_9(D) > > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > > calls > > > > > > or data references that cannot be analyzed > > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > > > showing that the "symbolic number of iterations" message is > > > > > > within > > > > > > the "=== analyze_loop_nest ===" (and not within the > > > > > > "=== vect_analyze_loop_form ==="). > > > > > > > > > > > > This is also enabling work for followups involving > > > > > > optimization > > > > > > records > > > > > > (allowing the records to directly capture the nested > > > > > > structure of > > > > > > the > > > > > > dump messages). > > > > > > > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux- > > > > > > gnu. > > > > > > > > > > > > OK for trunk? > > > > > > > > Hi, > > > > > > > > I've noticed that this patch (r262246) caused regressions on > > > > aarch64: > > > > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree- > > > > dump > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > > > > cancelled: can use load/store-lanes" > > > > > > > > The problem is that now there are more spaces between "note:" and > > > > "Built", the attached small patch does that for slp-perm-1.c. > > > > > > Sorry about the breakage. > > > > > > > Is it the right way of fixing it or do we want to accept any > > > > amount > > > > of > > > > spaces for instance? > > > > > > I don't think we want to hardcode the amount of space in the > > > dumpfile. > > > The idea of my patch was to make the dump more human-readable (I > > > hope) > > > by visualizing the nesting structure of the dump messages, but I > > > think > > > we shouldn't "bake" that into the expected strings, as someone > > > might > > > want to add an intermediate nesting level. > > > > > > Do we really need to look for the "note:" in the scan-tree-dump? > > > Should that directive be rewritten to: > > > > > > -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use > > > load/store-lanes" "vect" { target { vect_perm3_int && > > > vect_load_lanes } } } } */ > > > +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use > > > load/store-lanes" "vect" { target { vect_perm3_int && > > > vect_load_lanes } } } } */ > > > > > > which I believe would match any amount of spaces. > > > > > > Alternatively a regex accepting any amount of space ought to work, > > > if > > > we care that the message begins with "note: ". > > > > > > The "note: " comes from dumpfile.c's dump_loc, and is emitted > > > regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION > > > or > > > whatever. Given that, maybe we should just drop the "note: " > > > prefix > > > from these scan-tree-dump expected regexes? (assuming that works) > > > > I guess it was done for the -fopt-info output channel to match what > > we emit with inform () given those are neither warnings nor errors. > > > > But yes, lets elide "note: " from dumpfiles. Be prepared to fiddle > > with expected scan-dumps though. > > Re-reading, I think I was unclear, but I was proposing removing it from > the scan-tree-dump regexes, *not* from dumpfile.c (though I'm open to > the latter). Both is fine with me. Richard. > > > > > > I'm surprised there is such little impact on the testsuite > > > > though. > > > > > > I see lots of scan-tree-dump* directives in the vect part of the > > > testsuite, but it seems that only these ones use the "note: " > > > prefix; I > > > think everything else was matching against the message whilst > > > ignoring > > > the prefix, so it didn't matter when the prefix changed > > > (I double-checked and these scan-tree-dump directives didn't > > > trigger on > > > my x86_64 testing of the patch, due to { target { vect_perm3_int && > > > vect_load_lanes } }, where I see > > > check_effective_target_vect_load_lanes: returning 0 in the log) > > > > > > > If OK, I'll update the patch to take the other slp-perm- > > > > [235678].c > > > > tests into account. > > > > > > > > Thanks, > > > > > > > > Christophe > > > > > > Sorry again about the breakage. > > > Dave > > >
On Tue, 3 Jul 2018 at 15:53, Richard Biener <richard.guenther@gmail.com> wrote: > > On Tue, Jul 3, 2018 at 3:52 PM David Malcolm <dmalcolm@redhat.com> wrote: > > > > On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote: > > > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm <dmalcolm@redhat.com> > > > wrote: > > > > > > > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > > > > > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gm > > > > > ail. > > > > > com> wrote: > > > > > > > > > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat. > > > > > > com> > > > > > > wrote: > > > > > > > > > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > > > > > dump_*_loc > > > > > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > > > > > vectorizer.h, > > > > > > > so that the nested structure is shown in -fopt-info by > > > > > > > indentation. > > > > > > > > > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > > > test.c:8:3: note: === get_loop_niters === > > > > > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > > > > > int) > > > > > > > n_9(D) > > > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > > > calls or > > > > > > > data references that cannot be analyzed > > > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > > > > > to: > > > > > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > > > test.c:8:3: note: === get_loop_niters === > > > > > > > test.c:8:3: note: symbolic number of iterations is > > > > > > > (unsigned > > > > > > > int) n_9(D) > > > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > > > calls > > > > > > > or data references that cannot be analyzed > > > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > > > > > showing that the "symbolic number of iterations" message is > > > > > > > within > > > > > > > the "=== analyze_loop_nest ===" (and not within the > > > > > > > "=== vect_analyze_loop_form ==="). > > > > > > > > > > > > > > This is also enabling work for followups involving > > > > > > > optimization > > > > > > > records > > > > > > > (allowing the records to directly capture the nested > > > > > > > structure of > > > > > > > the > > > > > > > dump messages). > > > > > > > > > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux- > > > > > > > gnu. > > > > > > > > > > > > > > OK for trunk? > > > > > > > > > > Hi, > > > > > > > > > > I've noticed that this patch (r262246) caused regressions on > > > > > aarch64: > > > > > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree- > > > > > dump > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > > > > > cancelled: can use load/store-lanes" > > > > > > > > > > The problem is that now there are more spaces between "note:" and > > > > > "Built", the attached small patch does that for slp-perm-1.c. > > > > > > > > Sorry about the breakage. > > > > > > > > > Is it the right way of fixing it or do we want to accept any > > > > > amount > > > > > of > > > > > spaces for instance? > > > > > > > > I don't think we want to hardcode the amount of space in the > > > > dumpfile. > > > > The idea of my patch was to make the dump more human-readable (I > > > > hope) > > > > by visualizing the nesting structure of the dump messages, but I > > > > think > > > > we shouldn't "bake" that into the expected strings, as someone > > > > might > > > > want to add an intermediate nesting level. > > > > > > > > Do we really need to look for the "note:" in the scan-tree-dump? > > > > Should that directive be rewritten to: > > > > > > > > -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use > > > > load/store-lanes" "vect" { target { vect_perm3_int && > > > > vect_load_lanes } } } } */ > > > > +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use > > > > load/store-lanes" "vect" { target { vect_perm3_int && > > > > vect_load_lanes } } } } */ > > > > > > > > which I believe would match any amount of spaces. > > > > > > > > Alternatively a regex accepting any amount of space ought to work, > > > > if > > > > we care that the message begins with "note: ". > > > > > > > > The "note: " comes from dumpfile.c's dump_loc, and is emitted > > > > regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION > > > > or > > > > whatever. Given that, maybe we should just drop the "note: " > > > > prefix > > > > from these scan-tree-dump expected regexes? (assuming that works) > > > > > > I guess it was done for the -fopt-info output channel to match what > > > we emit with inform () given those are neither warnings nor errors. > > > > > > But yes, lets elide "note: " from dumpfiles. Be prepared to fiddle > > > with expected scan-dumps though. > > > > Re-reading, I think I was unclear, but I was proposing removing it from > > the scan-tree-dump regexes, *not* from dumpfile.c (though I'm open to > > the latter). > > Both is fine with me. > The attached patch removes 'note:' from the scan-tree-dump directives. Testing showed no regression, but I didn't exercise the gcc.target/i386 and gnat.dg parts. OK? > Richard. > > > > > > > > > I'm surprised there is such little impact on the testsuite > > > > > though. > > > > > > > > I see lots of scan-tree-dump* directives in the vect part of the > > > > testsuite, but it seems that only these ones use the "note: " > > > > prefix; I > > > > think everything else was matching against the message whilst > > > > ignoring > > > > the prefix, so it didn't matter when the prefix changed > > > > (I double-checked and these scan-tree-dump directives didn't > > > > trigger on > > > > my x86_64 testing of the patch, due to { target { vect_perm3_int && > > > > vect_load_lanes } }, where I see > > > > check_effective_target_vect_load_lanes: returning 0 in the log) > > > > > > > > > If OK, I'll update the patch to take the other slp-perm- > > > > > [235678].c > > > > > tests into account. > > > > > > > > > > Thanks, > > > > > > > > > > Christophe > > > > > > > > Sorry again about the breakage. > > > > Dave > > > > 2018-07-05 Christophe Lyon <christophe.lyon@linaro.org> * c-c++-common/unroll-1.c: Remove 'note:' in matching string. * c-c++-common/unroll-2.c: Likewise. * g++.dg/cdce3.C: Likewise. * g++.dg/ext/unroll-1.C: Likewise. * g++.dg/ext/unroll-2.C: Likewise. * g++.dg/ext/unroll-3.C: Likewise. * gcc.dg/cdce1.c: Likewise. * gcc.dg/cdce2.c: Likewise. * gcc.dg/gomp/pr68128-1.c: Likewise. * gcc.dg/vect/pr46032.c: Likewise. * gcc.dg/vect/vect-cond-10.c: Likewise. * gcc.dg/vect/vect-cond-8.c: Likewise. * gcc.dg/vect/vect-cond-9.c: Likewise. * gcc.dg/vect/vect-mask-load-1.c: Likewise. * gcc.dg/vect/vect-mask-loadstore-1.c: Likewise. * gcc.target/i386/avx-cvt-2.c: Likewise. * gcc.target/i386/avx-cvt-3.c: Likewise. * gcc.target/i386/avx2-cvt-2.c: Likewise. * gcc.target/i386/avx2-gather-2.c: Likewise. * gcc.target/i386/avx2-gather-6.c: Likewise. * gcc.target/i386/avx512f-gather-2.c: Likewise. * gcc.target/i386/sse2-cvt-2.c: Likewise. * gfortran.dg/directive_unroll_1.f90: Likewise. * gfortran.dg/directive_unroll_2.f90: Likewise. * gnat.dg/unroll2.adb: Likewise. * gnat.dg/unroll3.adb: Likewise. diff --git a/gcc/testsuite/c-c++-common/unroll-1.c b/gcc/testsuite/c-c++-common/unroll-1.c index ccae250..105a82c 100644 --- a/gcc/testsuite/c-c++-common/unroll-1.c +++ b/gcc/testsuite/c-c++-common/unroll-1.c @@ -10,12 +10,12 @@ void test (void) #pragma GCC unroll 8 for (unsigned long i = 1; i <= 8; ++i) bar(i); - /* { dg-final { scan-tree-dump "11:.*: note: loop with 8 iterations completely unrolled" "cunrolli" } } */ + /* { dg-final { scan-tree-dump "11:.*: loop with 8 iterations completely unrolled" "cunrolli" } } */ #pragma GCC unroll 8 for (unsigned long i = 1; i <= 7; ++i) bar(i); - /* { dg-final { scan-tree-dump "16:.*: note: loop with 7 iterations completely unrolled" "cunrolli" } } */ + /* { dg-final { scan-tree-dump "16:.*: loop with 7 iterations completely unrolled" "cunrolli" } } */ #pragma GCC unroll 8 for (unsigned long i = 1; i <= 15; ++i) diff --git a/gcc/testsuite/c-c++-common/unroll-2.c b/gcc/testsuite/c-c++-common/unroll-2.c index 635b6c2..a67a1d7 100644 --- a/gcc/testsuite/c-c++-common/unroll-2.c +++ b/gcc/testsuite/c-c++-common/unroll-2.c @@ -10,12 +10,12 @@ void test (void) #pragma GCC unroll 8 for (unsigned long i = 1; i <= 8; ++i) bar(i); - /* { dg-final { scan-tree-dump "11:.*: note: loop with 7 iterations completely unrolled" "cunroll" } } */ + /* { dg-final { scan-tree-dump "11:.*: loop with 7 iterations completely unrolled" "cunroll" } } */ #pragma GCC unroll 8 for (unsigned long i = 1; i <= 7; ++i) bar(i); - /* { dg-final { scan-tree-dump "16:.*: note: loop with 6 iterations completely unrolled" "cunroll" } } */ + /* { dg-final { scan-tree-dump "16:.*: loop with 6 iterations completely unrolled" "cunroll" } } */ #pragma GCC unroll 8 for (unsigned long i = 1; i <= 15; ++i) diff --git a/gcc/testsuite/g++.dg/cdce3.C b/gcc/testsuite/g++.dg/cdce3.C index 3937953..4b547b5 100644 --- a/gcc/testsuite/g++.dg/cdce3.C +++ b/gcc/testsuite/g++.dg/cdce3.C @@ -4,22 +4,22 @@ /* { dg-additional-options "-DLARGE_LONG_DOUBLE" { target large_long_double } } */ /* { dg-additional-options "-DGNU_EXTENSION" { target pow10 } } */ /* { dg-add-options ieee } */ -/* { dg-final { scan-tree-dump "cdce3.C:91: note: function call is shrink-wrapped into error conditions\." "cdce" { target pow10 } } } */ -/* { dg-final { scan-tree-dump "cdce3.C:92: note: function call is shrink-wrapped into error conditions\." "cdce" { target pow10 } } } */ -/* { dg-final { scan-tree-dump "cdce3.C:94: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:95: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:96: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:97: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:98: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:99: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:100: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:101: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:102: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:103: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:104: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:105: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:106: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ -/* { dg-final { scan-tree-dump "cdce3.C:107: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:91: .* function call is shrink-wrapped into error conditions\." "cdce" { target pow10 } } } */ +/* { dg-final { scan-tree-dump "cdce3.C:92: .* function call is shrink-wrapped into error conditions\." "cdce" { target pow10 } } } */ +/* { dg-final { scan-tree-dump "cdce3.C:94: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:95: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:96: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:97: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:98: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:99: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:100: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:101: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:102: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:103: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:104: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:105: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:106: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce3.C:107: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ #include <stdlib.h> #include <math.h> diff --git a/gcc/testsuite/g++.dg/ext/unroll-1.C b/gcc/testsuite/g++.dg/ext/unroll-1.C index 2d58a6a..aa11b2e 100644 --- a/gcc/testsuite/g++.dg/ext/unroll-1.C +++ b/gcc/testsuite/g++.dg/ext/unroll-1.C @@ -16,4 +16,4 @@ bar (int *a, int *b, int *c) foo <int> (a, b, c); } -// { dg-final { scan-tree-dump "note: loop with 8 iterations completely unrolled" "cunrolli" } } +// { dg-final { scan-tree-dump "loop with 8 iterations completely unrolled" "cunrolli" } } diff --git a/gcc/testsuite/g++.dg/ext/unroll-2.C b/gcc/testsuite/g++.dg/ext/unroll-2.C index e68cc31..f9ec892 100644 --- a/gcc/testsuite/g++.dg/ext/unroll-2.C +++ b/gcc/testsuite/g++.dg/ext/unroll-2.C @@ -10,4 +10,4 @@ foo (int (&a)[8], int *b, int *c) a[i] = b[i] * c[i]; } -// { dg-final { scan-tree-dump "note: loop with 8 iterations completely unrolled" "cunrolli" } } +// { dg-final { scan-tree-dump "loop with 8 iterations completely unrolled" "cunrolli" } } diff --git a/gcc/testsuite/g++.dg/ext/unroll-3.C b/gcc/testsuite/g++.dg/ext/unroll-3.C index 6516ee9..dda94c5 100644 --- a/gcc/testsuite/g++.dg/ext/unroll-3.C +++ b/gcc/testsuite/g++.dg/ext/unroll-3.C @@ -17,4 +17,4 @@ bar (int (&a)[8], int *b, int *c) foo <int> (a, b, c); } -// { dg-final { scan-tree-dump "note: loop with 8 iterations completely unrolled" "cunrolli" } } +// { dg-final { scan-tree-dump "loop with 8 iterations completely unrolled" "cunrolli" } } diff --git a/gcc/testsuite/gcc.dg/cdce1.c b/gcc/testsuite/gcc.dg/cdce1.c index 02b47c0..b23ad63 100644 --- a/gcc/testsuite/gcc.dg/cdce1.c +++ b/gcc/testsuite/gcc.dg/cdce1.c @@ -1,7 +1,7 @@ /* { dg-do run } */ /* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details -lm" } */ /* { dg-require-effective-target int32plus } */ -/* { dg-final { scan-tree-dump "cdce1.c:16: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce1.c:16: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ /* { dg-require-effective-target large_double } */ #include <stdlib.h> diff --git a/gcc/testsuite/gcc.dg/cdce2.c b/gcc/testsuite/gcc.dg/cdce2.c index 9e6f344..30e7cb1 100644 --- a/gcc/testsuite/gcc.dg/cdce2.c +++ b/gcc/testsuite/gcc.dg/cdce2.c @@ -1,7 +1,7 @@ /* { dg-do run } */ /* { dg-skip-if "doubles are floats" { "avr-*-*" } } */ /* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details -lm" } */ -/* { dg-final { scan-tree-dump "cdce2.c:15: note: function call is shrink-wrapped into error conditions\." "cdce" } } */ +/* { dg-final { scan-tree-dump "cdce2.c:15: .* function call is shrink-wrapped into error conditions\." "cdce" } } */ #include <stdlib.h> #include <math.h> diff --git a/gcc/testsuite/gcc.dg/gomp/pr68128-1.c b/gcc/testsuite/gcc.dg/gomp/pr68128-1.c index 36823c2..01cc605 100644 --- a/gcc/testsuite/gcc.dg/gomp/pr68128-1.c +++ b/gcc/testsuite/gcc.dg/gomp/pr68128-1.c @@ -29,4 +29,4 @@ foo (float *u, float v, float w, float x, float y, float z, float t) } } -/* { dg-final { scan-tree-dump "note: vectorized 1 loops in function" "vect" { target i?86-*-* x86_64-*-* } } } */ +/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" { target i?86-*-* x86_64-*-* } } } */ diff --git a/gcc/testsuite/gcc.dg/vect/pr46032.c b/gcc/testsuite/gcc.dg/vect/pr46032.c index e1a5834..bad8745 100644 --- a/gcc/testsuite/gcc.dg/vect/pr46032.c +++ b/gcc/testsuite/gcc.dg/vect/pr46032.c @@ -44,6 +44,6 @@ main (void) return 0; } -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loop" 1 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loop" 1 "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */ /* { dg-final { scan-tree-dump-not "versioning for alias required" "vect" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/vect-cond-10.c b/gcc/testsuite/gcc.dg/vect/vect-cond-10.c index 1a18800..b2f97d7 100644 --- a/gcc/testsuite/gcc.dg/vect/vect-cond-10.c +++ b/gcc/testsuite/gcc.dg/vect/vect-cond-10.c @@ -163,4 +163,4 @@ main () return 0; } -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops" 8 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 8 "vect" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/vect-cond-8.c b/gcc/testsuite/gcc.dg/vect/vect-cond-8.c index 224251d..d888442 100644 --- a/gcc/testsuite/gcc.dg/vect/vect-cond-8.c +++ b/gcc/testsuite/gcc.dg/vect/vect-cond-8.c @@ -119,4 +119,4 @@ main () return 0; } -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops" 5 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 5 "vect" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/vect-cond-9.c b/gcc/testsuite/gcc.dg/vect/vect-cond-9.c index c03ed96..63eee1b 100644 --- a/gcc/testsuite/gcc.dg/vect/vect-cond-9.c +++ b/gcc/testsuite/gcc.dg/vect/vect-cond-9.c @@ -198,4 +198,4 @@ main () return 0; } -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops" 10 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 10 "vect" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/vect-mask-load-1.c b/gcc/testsuite/gcc.dg/vect/vect-mask-load-1.c index 3a38b64..992cbda 100644 --- a/gcc/testsuite/gcc.dg/vect/vect-mask-load-1.c +++ b/gcc/testsuite/gcc.dg/vect/vect-mask-load-1.c @@ -46,4 +46,4 @@ main () return 0; } -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops" 1 "vect" { target avx_runtime } } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target avx_runtime } } } */ diff --git a/gcc/testsuite/gcc.dg/vect/vect-mask-loadstore-1.c b/gcc/testsuite/gcc.dg/vect/vect-mask-loadstore-1.c index 56b130e..7d9dc5a 100644 --- a/gcc/testsuite/gcc.dg/vect/vect-mask-loadstore-1.c +++ b/gcc/testsuite/gcc.dg/vect/vect-mask-loadstore-1.c @@ -44,4 +44,4 @@ main () return 0; } -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops" 1 "vect" { target avx_runtime } } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target avx_runtime } } } */ diff --git a/gcc/testsuite/gcc.target/i386/avx-cvt-2.c b/gcc/testsuite/gcc.target/i386/avx-cvt-2.c index 7380833..1fbcf6e 100644 --- a/gcc/testsuite/gcc.target/i386/avx-cvt-2.c +++ b/gcc/testsuite/gcc.target/i386/avx-cvt-2.c @@ -3,7 +3,7 @@ #include "avx-cvt-1.c" -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 6 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */ /* { dg-final { scan-assembler "vcvttpd2dq(y\[^\n\r\]*%xmm|\[^\n\r\]*xmm\[^\n\r\]*YMMWORD PTR)" } } */ /* { dg-final { scan-assembler "vcvtdq2ps\[^\n\r\]*ymm" } } */ /* { dg-final { scan-assembler "vcvtps2pd\[^\n\r\]*(%xmm\[^\n\r\]*%ymm|ymm\[^\n\r\]*xmm)" } } */ diff --git a/gcc/testsuite/gcc.target/i386/avx-cvt-3.c b/gcc/testsuite/gcc.target/i386/avx-cvt-3.c index de2e482..33af620 100644 --- a/gcc/testsuite/gcc.target/i386/avx-cvt-3.c +++ b/gcc/testsuite/gcc.target/i386/avx-cvt-3.c @@ -3,7 +3,7 @@ #include "avx-cvt-1.c" -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 6 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */ /* { dg-final { scan-assembler "vcvttpd2dq(x\[^\n\r\]*%xmm|\[^\n\r\]*xmm\[^\n\r\]*XMMWORD PTR)" } } */ /* { dg-final { scan-assembler "vcvtdq2ps\[^\n\r\]*xmm" } } */ /* { dg-final { scan-assembler "vcvtps2pd\[^\n\r\]*(%xmm\[^\n\r\]*%xmm|xmm\[^\n\r\]*xmm)" } } */ diff --git a/gcc/testsuite/gcc.target/i386/avx2-cvt-2.c b/gcc/testsuite/gcc.target/i386/avx2-cvt-2.c index 317c2c0..d37809d 100644 --- a/gcc/testsuite/gcc.target/i386/avx2-cvt-2.c +++ b/gcc/testsuite/gcc.target/i386/avx2-cvt-2.c @@ -3,7 +3,7 @@ #include "avx2-cvt-1.c" -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 6 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */ /* { dg-final { scan-assembler "vcvttpd2dq(y\[^\n\r\]*%xmm|\[^\n\r\]*xmm\[^\n\r\]*YMMWORD PTR)" } } */ /* { dg-final { scan-assembler "vcvtdq2ps\[^\n\r\]*ymm" } } */ /* { dg-final { scan-assembler "vcvtps2pd\[^\n\r\]*(%xmm\[^\n\r\]*%ymm|ymm\[^\n\r\]*xmm)" } } */ diff --git a/gcc/testsuite/gcc.target/i386/avx2-gather-2.c b/gcc/testsuite/gcc.target/i386/avx2-gather-2.c index e080323..1a704af 100644 --- a/gcc/testsuite/gcc.target/i386/avx2-gather-2.c +++ b/gcc/testsuite/gcc.target/i386/avx2-gather-2.c @@ -3,4 +3,4 @@ #include "avx2-gather-1.c" -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 16 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 16 "vect" } } */ diff --git a/gcc/testsuite/gcc.target/i386/avx2-gather-6.c b/gcc/testsuite/gcc.target/i386/avx2-gather-6.c index 0ffb04f..b911958 100644 --- a/gcc/testsuite/gcc.target/i386/avx2-gather-6.c +++ b/gcc/testsuite/gcc.target/i386/avx2-gather-6.c @@ -3,4 +3,4 @@ #include "avx2-gather-5.c" -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 1 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" } } */ diff --git a/gcc/testsuite/gcc.target/i386/avx512f-gather-2.c b/gcc/testsuite/gcc.target/i386/avx512f-gather-2.c index e52a0ef..a26aa65 100644 --- a/gcc/testsuite/gcc.target/i386/avx512f-gather-2.c +++ b/gcc/testsuite/gcc.target/i386/avx512f-gather-2.c @@ -7,4 +7,4 @@ /* { dg-final { scan-assembler-not "gather\[^\n\]*xmm\[^\n\]*ymm" } } */ /* { dg-final { scan-assembler-not "gather\[^\n\]*ymm\[^\n\]*xmm" } } */ /* { dg-final { scan-assembler-not "gather\[^\n\]*xmm\[^\n\]*xmm" } } */ -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 16 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 16 "vect" } } */ diff --git a/gcc/testsuite/gcc.target/i386/sse2-cvt-2.c b/gcc/testsuite/gcc.target/i386/sse2-cvt-2.c index 97bd1fd..0ecafb2 100644 --- a/gcc/testsuite/gcc.target/i386/sse2-cvt-2.c +++ b/gcc/testsuite/gcc.target/i386/sse2-cvt-2.c @@ -3,7 +3,7 @@ #include "sse2-cvt-1.c" -/* { dg-final { scan-tree-dump-times "note: vectorized 1 loops in function" 6 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 6 "vect" } } */ /* { dg-final { scan-assembler "cvttpd2dq" } } */ /* { dg-final { scan-assembler "cvtdq2ps" } } */ /* { dg-final { scan-assembler "cvtps2pd" } } */ diff --git a/gcc/testsuite/gfortran.dg/directive_unroll_1.f90 b/gcc/testsuite/gfortran.dg/directive_unroll_1.f90 index 00fe7dc..85b3671 100644 --- a/gcc/testsuite/gfortran.dg/directive_unroll_1.f90 +++ b/gcc/testsuite/gfortran.dg/directive_unroll_1.f90 @@ -12,7 +12,7 @@ subroutine test1(a) DO i=1, 8, 1 call dummy(a(i)) ENDDO -! { dg-final { scan-tree-dump "12:.*: note: loop with 8 iterations completely unrolled" "cunrolli" } } */ +! { dg-final { scan-tree-dump "12:.*: loop with 8 iterations completely unrolled" "cunrolli" } } */ end subroutine test1 subroutine test2(a, n) diff --git a/gcc/testsuite/gfortran.dg/directive_unroll_2.f90 b/gcc/testsuite/gfortran.dg/directive_unroll_2.f90 index bc93f91..6dff8fa 100644 --- a/gcc/testsuite/gfortran.dg/directive_unroll_2.f90 +++ b/gcc/testsuite/gfortran.dg/directive_unroll_2.f90 @@ -12,7 +12,7 @@ subroutine test1(a) DO i=1, 8, 1 call dummy(a(i)) ENDDO -! { dg-final { scan-tree-dump "12:.*: note: loop with 7 iterations completely unrolled" "cunroll" } } */ +! { dg-final { scan-tree-dump "12:.*: loop with 7 iterations completely unrolled" "cunroll" } } */ end subroutine test1 subroutine test2(a, n) diff --git a/gcc/testsuite/gnat.dg/unroll2.adb b/gcc/testsuite/gnat.dg/unroll2.adb index e4473cc..1d3a757 100644 --- a/gcc/testsuite/gnat.dg/unroll2.adb +++ b/gcc/testsuite/gnat.dg/unroll2.adb @@ -23,4 +23,4 @@ package body Unroll2 is end Unroll2; --- { dg-final { scan-tree-dump-times "note: loop with 3 iterations completely unrolled" 2 "cunrolli" } } +-- { dg-final { scan-tree-dump-times "loop with 3 iterations completely unrolled" 2 "cunrolli" } } diff --git a/gcc/testsuite/gnat.dg/unroll3.adb b/gcc/testsuite/gnat.dg/unroll3.adb index ba4e122..3bd06e7 100644 --- a/gcc/testsuite/gnat.dg/unroll3.adb +++ b/gcc/testsuite/gnat.dg/unroll3.adb @@ -23,4 +23,4 @@ package body Unroll3 is end Unroll3; --- { dg-final { scan-tree-dump-times "note: loop with 3 iterations completely unrolled" 2 "cunroll" } } +-- { dg-final { scan-tree-dump-times "loop with 3 iterations completely unrolled" 2 "cunroll" } }
On Thu, Jul 5, 2018 at 10:42 AM Christophe Lyon <christophe.lyon@linaro.org> wrote: > > On Tue, 3 Jul 2018 at 15:53, Richard Biener <richard.guenther@gmail.com> wrote: > > > > On Tue, Jul 3, 2018 at 3:52 PM David Malcolm <dmalcolm@redhat.com> wrote: > > > > > > On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote: > > > > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm <dmalcolm@redhat.com> > > > > wrote: > > > > > > > > > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote: > > > > > > On Fri, 29 Jun 2018 at 10:09, Richard Biener <richard.guenther@gm > > > > > > ail. > > > > > > com> wrote: > > > > > > > > > > > > > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm <dmalcolm@redhat. > > > > > > > com> > > > > > > > wrote: > > > > > > > > > > > > > > > > This patch adds a concept of nested "scopes" to dumpfile.c's > > > > > > > > dump_*_loc > > > > > > > > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree- > > > > > > > > vectorizer.h, > > > > > > > > so that the nested structure is shown in -fopt-info by > > > > > > > > indentation. > > > > > > > > > > > > > > > > For example, this converts -fopt-info-all e.g. from: > > > > > > > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > > > > test.c:8:3: note: === get_loop_niters === > > > > > > > > test.c:8:3: note: symbolic number of iterations is (unsigned > > > > > > > > int) > > > > > > > > n_9(D) > > > > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > > > > calls or > > > > > > > > data references that cannot be analyzed > > > > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > > > > > > > to: > > > > > > > > > > > > > > > > test.c:8:3: note: === analyzing loop === > > > > > > > > test.c:8:3: note: === analyze_loop_nest === > > > > > > > > test.c:8:3: note: === vect_analyze_loop_form === > > > > > > > > test.c:8:3: note: === get_loop_niters === > > > > > > > > test.c:8:3: note: symbolic number of iterations is > > > > > > > > (unsigned > > > > > > > > int) n_9(D) > > > > > > > > test.c:8:3: note: not vectorized: loop contains function > > > > > > > > calls > > > > > > > > or data references that cannot be analyzed > > > > > > > > test.c:8:3: note: vectorized 0 loops in function > > > > > > > > > > > > > > > > showing that the "symbolic number of iterations" message is > > > > > > > > within > > > > > > > > the "=== analyze_loop_nest ===" (and not within the > > > > > > > > "=== vect_analyze_loop_form ==="). > > > > > > > > > > > > > > > > This is also enabling work for followups involving > > > > > > > > optimization > > > > > > > > records > > > > > > > > (allowing the records to directly capture the nested > > > > > > > > structure of > > > > > > > > the > > > > > > > > dump messages). > > > > > > > > > > > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux- > > > > > > > > gnu. > > > > > > > > > > > > > > > > OK for trunk? > > > > > > > > > > > > Hi, > > > > > > > > > > > > I've noticed that this patch (r262246) caused regressions on > > > > > > aarch64: > > > > > > gcc.dg/vect/slp-perm-1.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-1.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-2.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-2.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-3.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-3.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-5.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-5.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-6.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-6.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-7.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-7.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects scan-tree- > > > > > > dump > > > > > > vect "note: Built SLP cancelled: can use load/store-lanes" > > > > > > gcc.dg/vect/slp-perm-8.c scan-tree-dump vect "note: Built SLP > > > > > > cancelled: can use load/store-lanes" > > > > > > > > > > > > The problem is that now there are more spaces between "note:" and > > > > > > "Built", the attached small patch does that for slp-perm-1.c. > > > > > > > > > > Sorry about the breakage. > > > > > > > > > > > Is it the right way of fixing it or do we want to accept any > > > > > > amount > > > > > > of > > > > > > spaces for instance? > > > > > > > > > > I don't think we want to hardcode the amount of space in the > > > > > dumpfile. > > > > > The idea of my patch was to make the dump more human-readable (I > > > > > hope) > > > > > by visualizing the nesting structure of the dump messages, but I > > > > > think > > > > > we shouldn't "bake" that into the expected strings, as someone > > > > > might > > > > > want to add an intermediate nesting level. > > > > > > > > > > Do we really need to look for the "note:" in the scan-tree-dump? > > > > > Should that directive be rewritten to: > > > > > > > > > > -/* { dg-final { scan-tree-dump "note: Built SLP cancelled: can use > > > > > load/store-lanes" "vect" { target { vect_perm3_int && > > > > > vect_load_lanes } } } } */ > > > > > +/* { dg-final { scan-tree-dump "Built SLP cancelled: can use > > > > > load/store-lanes" "vect" { target { vect_perm3_int && > > > > > vect_load_lanes } } } } */ > > > > > > > > > > which I believe would match any amount of spaces. > > > > > > > > > > Alternatively a regex accepting any amount of space ought to work, > > > > > if > > > > > we care that the message begins with "note: ". > > > > > > > > > > The "note: " comes from dumpfile.c's dump_loc, and is emitted > > > > > regardless of whether it's a MSG_NOTE vs a MSG_MISSED_OPTIMIZATION > > > > > or > > > > > whatever. Given that, maybe we should just drop the "note: " > > > > > prefix > > > > > from these scan-tree-dump expected regexes? (assuming that works) > > > > > > > > I guess it was done for the -fopt-info output channel to match what > > > > we emit with inform () given those are neither warnings nor errors. > > > > > > > > But yes, lets elide "note: " from dumpfiles. Be prepared to fiddle > > > > with expected scan-dumps though. > > > > > > Re-reading, I think I was unclear, but I was proposing removing it from > > > the scan-tree-dump regexes, *not* from dumpfile.c (though I'm open to > > > the latter). > > > > Both is fine with me. > > > > The attached patch removes 'note:' from the scan-tree-dump directives. > Testing showed no regression, but I didn't exercise the > gcc.target/i386 and gnat.dg parts. > > OK? OK. RIchard. > > Richard. > > > > > > > > > > > > I'm surprised there is such little impact on the testsuite > > > > > > though. > > > > > > > > > > I see lots of scan-tree-dump* directives in the vect part of the > > > > > testsuite, but it seems that only these ones use the "note: " > > > > > prefix; I > > > > > think everything else was matching against the message whilst > > > > > ignoring > > > > > the prefix, so it didn't matter when the prefix changed > > > > > (I double-checked and these scan-tree-dump directives didn't > > > > > trigger on > > > > > my x86_64 testing of the patch, due to { target { vect_perm3_int && > > > > > vect_load_lanes } }, where I see > > > > > check_effective_target_vect_load_lanes: returning 0 in the log) > > > > > > > > > > > If OK, I'll update the patch to take the other slp-perm- > > > > > > [235678].c > > > > > > tests into account. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Christophe > > > > > > > > > > Sorry again about the breakage. > > > > > Dave > > > > >
diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c index 122e420..190b52d 100644 --- a/gcc/dumpfile.c +++ b/gcc/dumpfile.c @@ -419,6 +419,8 @@ dump_loc (dump_flags_t dump_kind, FILE *dfile, source_location loc) DECL_SOURCE_FILE (current_function_decl), DECL_SOURCE_LINE (current_function_decl), DECL_SOURCE_COLUMN (current_function_decl)); + /* Indentation based on scope depth. */ + fprintf (dfile, "%*s", get_dump_scope_depth (), ""); } } @@ -539,6 +541,39 @@ template void dump_dec (dump_flags_t, const poly_uint64 &); template void dump_dec (dump_flags_t, const poly_offset_int &); template void dump_dec (dump_flags_t, const poly_widest_int &); +/* The current dump scope-nesting depth. */ + +static int dump_scope_depth; + +/* Get the current dump scope-nesting depth. + For use by dump_*_loc (for showing nesting via indentation). */ + +unsigned int +get_dump_scope_depth () +{ + return dump_scope_depth; +} + +/* Push a nested dump scope. + Print "=== NAME ===\n" to the dumpfile, if any, and to the -fopt-info + destination, if any. + Increment the scope depth. */ + +void +dump_begin_scope (const char *name, const dump_location_t &loc) +{ + dump_printf_loc (MSG_NOTE, loc, "=== %s ===\n", name); + dump_scope_depth++; +} + +/* Pop a nested dump scope. */ + +void +dump_end_scope () +{ + dump_scope_depth--; +} + /* Start a dump for PHASE. Store user-supplied dump flags in *FLAG_PTR. Return the number of streams opened. Set globals DUMP_FILE, and ALT_DUMP_FILE to point to the opened streams, and diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h index 90d8930..89d5c11 100644 --- a/gcc/dumpfile.h +++ b/gcc/dumpfile.h @@ -456,6 +456,45 @@ dump_enabled_p (void) return (dump_file || alt_dump_file); } +/* Managing nested scopes, so that dumps can express the call chain + leading to a dump message. */ + +extern unsigned int get_dump_scope_depth (); +extern void dump_begin_scope (const char *name, const dump_location_t &loc); +extern void dump_end_scope (); + +/* Implementation detail of the AUTO_DUMP_SCOPE macro below. + + A RAII-style class intended to make it easy to emit dump + information about entering and exiting a collection of nested + function calls. */ + +class auto_dump_scope +{ + public: + auto_dump_scope (const char *name, dump_location_t loc) + { + if (dump_enabled_p ()) + dump_begin_scope (name, loc); + } + ~auto_dump_scope () + { + if (dump_enabled_p ()) + dump_end_scope (); + } +}; + +/* A macro for calling: + dump_begin_scope (NAME, LOC); + via an RAII object, thus printing "=== MSG ===\n" to the dumpfile etc, + and then calling + dump_end_scope (); + once the object goes out of scope, thus capturing the nesting of + the scopes. */ + +#define AUTO_DUMP_SCOPE(NAME, LOC) \ + auto_dump_scope scope (NAME, LOC) + namespace gcc { class dump_manager diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h index 94a0f38..a8406b3 100644 --- a/gcc/tree-vectorizer.h +++ b/gcc/tree-vectorizer.h @@ -1440,15 +1440,16 @@ vect_get_scalar_dr_size (struct data_reference *dr) /* Source location + hotness information. */ extern dump_user_location_t vect_location; -/* If dumping is enabled, emit a MSG_NOTE at vect_location about - entering MSG within the vectorizer. MSG should be a string literal. */ +/* A macro for calling: + dump_begin_scope (MSG, vect_location); + via an RAII object, thus printing "=== MSG ===\n" to the dumpfile etc, + and then calling + dump_end_scope (); + once the object goes out of scope, thus capturing the nesting of + the scopes. */ #define DUMP_VECT_SCOPE(MSG) \ - do { \ - if (dump_enabled_p ()) \ - dump_printf_loc (MSG_NOTE, vect_location, \ - "=== " MSG " ===\n"); \ - } while (0) + AUTO_DUMP_SCOPE (MSG, vect_location) /*-----------------------------------------------------------------*/ /* Function prototypes. */