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: New GCC options for loop vectorization


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]