This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: minor help message fix


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 Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]