On Fri, Feb 7, 2014 at 6:15 PM, Xinliang David Li <davi...@google.com> wrote: > On Fri, Feb 7, 2014 at 1:22 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li <davi...@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
