Re: New GCC options for loop vectorization

[Xinliang David Li <davidxl at google dot com>]

New patch attached.

1) the peeling part is removed
2) the new patch implements the last-one-wins logic. -ftree-vectorize
behaves like a true alias. -fno-tree-vectorize can override previous
-ftree-xxx-vectorize.

Ok for trunk after testing?

thanks,

David

On Fri, Sep 13, 2013 at 8:16 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li <davidxl@google.com> wrote:
>>> Currently -ftree-vectorize turns on both loop and slp vectorizations,
>>> but there is no simple way to turn on loop vectorization alone. The
>>> logic for default O3 setting is also complicated.
>>>
>>> In this patch, two new options are introduced:
>>>
>>> 1) -ftree-loop-vectorize
>>>
>>> This option is used to turn on loop vectorization only. option
>>> -ftree-slp-vectorize also becomes a first class citizen, and no funny
>>> business of Init(2) is needed.  With this change, -ftree-vectorize
>>> becomes a simple alias to -ftree-loop-vectorize +
>>> -ftree-slp-vectorize.
>>>
>>> For instance, to turn on only slp vectorize at O3, the old way is:
>>>
>>>      -O3 -fno-tree-vectorize -ftree-slp-vectorize
>>>
>>> With the new change it becomes:
>>>
>>>     -O3 -fno-loop-vectorize
>>>
>>>
>>> To turn on only loop vectorize at O2, the old way is
>>>
>>>     -O2 -ftree-vectorize -fno-slp-vectorize
>>>
>>> The new way is
>>>
>>>     -O2 -ftree-loop-vectorize
>>>
>>>
>>>
>>> 2) -ftree-vect-loop-peeling
>>>
>>> This option is used to turn on/off loop peeling for alignment.  In the
>>> long run, this should be folded into the cheap cost model proposed by
>>> Richard.  This option is also useful in scenarios where peeling can
>>> introduce runtime problems:
>>> http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html  which happens to be
>>> common in practice.
>>>
>>>
>>>
>>> Patch attached. Compiler boostrapped. Ok after testing?
>>
>> I'd like you to split 1) and 2), mainly because I agree on 1) but not on 2).
>
> Ok. Can you also comment on 2) ?
>
>>
>> I've stopped a quick try doing 1) myself because
>>
>> @@ -1691,6 +1695,12 @@ common_handle_option (struct gcc_options
>>          opts->x_flag_ipa_reference = false;
>>        break;
>>
>> +    case OPT_ftree_vectorize:
>> +      if (!opts_set->x_flag_tree_loop_vectorize)
>> + opts->x_flag_tree_loop_vectorize = value;
>> +      if (!opts_set->x_flag_tree_slp_vectorize)
>> + opts->x_flag_tree_slp_vectorize = value;
>> +      break;
>>
>> doesn't look obviously correct.  Does that handle
>>
>>   -ftree-vectorize -fno-tree-loop-vectorize -ftree-vectorize
>>
>> or
>>
>>   -ftree-loop-vectorize -fno-tree-vectorize
>>
>> properly?  Currently at least
>>
>>   -ftree-slp-vectorize -fno-tree-vectorize
>>
>> doesn't "work".
>
>
> Right -- same is true for -fprofile-use option. FDO enables some
> passes, but can not re-enable them if they are flipped off before.
>
>>
>> That said, the option machinery doesn't handle an option being an alias
>> for two other options, so it's mechanism to contract positives/negatives
>> doesn't work here and the override hooks do not work reliably for
>> repeated options.
>>
>> Or am I wrong here?  Should we care at all?  Joseph?
>
> We should probably just document the behavior. Even better, we should
> deprecate the old option.
>
> thanks,
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>>
>>> thanks,
>>>
>>> David

Attachment: vect_new_opts_p1.txt
Description: Text document