| Message ID | CAAkRFZLzYn3xhPCn6bkiEgzAr8G6sfbWJZ_FhGzZOg+1Mep2eQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li <davidxl@google.com> wrote: > Hi the following patch removes the 'state' print for > -ftree-tree-vectorize option which does not make sense anymore. Ok for > trunk? Hmm, isn't it more appropriate to remove 'Report' from ftree-vectorize in common.opt? Or simply treat the [enabled]/[disabled] literally? Or simply also enable (redundantly) OPT_ftree_vectorize at -O3? Richard. > thanks, > > David
On Fri, Feb 7, 2014 at 1:22 AM, Richard Biener <richard.guenther@gmail.com> wrote: > On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li <davidxl@google.com> wrote: >> Hi the following patch removes the 'state' print for >> -ftree-tree-vectorize option which does not make sense anymore. Ok for >> trunk? > > Hmm, isn't it more appropriate to remove 'Report' from ftree-vectorize > in common.opt? For a supported option, we should probably report it. Do we want to deprecate it in the future? > Or simply treat the [enabled]/[disabled] literally? Not clear what you mean. I was thinking putting something like [see -ftree-loop-vectorize and -ftree-slp-vectorize] but it wraps around and looks bad. > Or simply also enable (redundantly) OPT_ftree_vectorize at -O3? This does not feel right. The flag does not represent one single optimization. Imaging we have a default level where loop vectorize is on, but slp is off (O2 will likely end up like that), what will the enable/disable state for tree-vectorize? David > > Richard. > >> thanks, >> >> David
On Fri, Feb 7, 2014 at 6:15 PM, Xinliang David Li <davidxl@google.com> wrote: > On Fri, Feb 7, 2014 at 1:22 AM, Richard Biener > <richard.guenther@gmail.com> wrote: >> On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li <davidxl@google.com> wrote: >>> Hi the following patch removes the 'state' print for >>> -ftree-tree-vectorize option which does not make sense anymore. Ok for >>> trunk? >> >> Hmm, isn't it more appropriate to remove 'Report' from ftree-vectorize >> in common.opt? > > For a supported option, we should probably report it. Do we want to > deprecate it in the future? > >> Or simply treat the [enabled]/[disabled] literally? > > Not clear what you mean. If -ftree-vectorize was not specified then it's not enabled (even when both -ftree-slp-vectorize and -ftree-loop-vectorize are). > I was thinking putting something like [see > -ftree-loop-vectorize and -ftree-slp-vectorize] but it wraps around > and looks bad. > >> Or simply also enable (redundantly) OPT_ftree_vectorize at -O3? > > This does not feel right. The flag does not represent one single > optimization. Imaging we have a default level where loop vectorize is > on, but slp is off (O2 will likely end up like that), what will the > enable/disable state for tree-vectorize? off I don't have a very good suggestion on how to treat these compound opts. What do we do with -ffast-math or other cases? I suppose the compound opts should be marked specially in the opt file so we can list it and its "sub" options in a group. Richard. > David > > >> >> Richard. >> >>> thanks, >>> >>> David
Index: ChangeLog =================================================================== --- ChangeLog (revision 207581) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2014-02-06 Xinliang David Li <davidxl@google.com> + + * opts.c (print_filtered_help): Fix help message bug. + 2014-02-06 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): New table. Index: opts.c =================================================================== --- opts.c (revision 207581) +++ opts.c (working copy) @@ -1060,8 +1060,11 @@ print_filtered_help (unsigned int includ "%#x", * (int *) flag_var); } else - strcat (new_help, option_enabled (i, opts) - ? _("[enabled]") : _("[disabled]")); + { + if (i != OPT_ftree_vectorize) + strcat (new_help, option_enabled (i, opts) + ? _("[enabled]") : _("[disabled]")); + } } help = new_help;