This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New GCC options for loop vectorization
- From: Xinliang David Li <davidxl at google dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 13 Sep 2013 08:16:52 -0700
- Subject: Re: New GCC options for loop vectorization
- Authentication-results: sourceware.org; auth=none
- References: <CAAkRFZJzPkDJe=y2RqDwXsegN1So-u8mvUM2Cc2=4yZm29ip5g at mail dot gmail dot com> <CAFiYyc204YzVZVSOKnzomiMZs0Spe7=8AMUz+ho-xzr6beahXg at mail dot gmail dot com>
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