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: [Patch (preapproved)] Guard Copy Header pass on flag_tree_loop_vectorize


On Tue, Aug 1, 2017 at 12:08 PM, James Greenhalgh
<james.greenhalgh@arm.com> wrote:
>
> On Thu, Jul 27, 2017 at 03:21:01PM +0100, James Greenhalgh wrote:
>> On Thu, Jul 27, 2017 at 02:26:03PM +0200, Richard Biener wrote:
>> > On Thu, Jul 27, 2017 at 2:08 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > > On Thu, Jul 27, 2017 at 01:54:21PM +0200, Richard Biener wrote:
>> > >> --- gcc/common.opt      (revision 250619)
>> > >> +++ gcc/common.opt      (working copy)
>> > >>  ftree-vectorize
>> > >> -Common Report Var(flag_tree_vectorize) Optimization
>> > >> +Common Report Optimization
>> > >>  Enable vectorization on trees.
>> > >>
>> > >>  ftree-vectorizer-verbose=
>> > >>
>> > >> which shows a few other uses of flag_tree_vectorize:
>> > >>
>> > >> int
>> > >> omp_max_vf (void)
>> > >> {
>> > >>   if (!optimize
>> > >>       || optimize_debug
>> > >>       || !flag_tree_loop_optimize
>> > >>       || (!flag_tree_loop_vectorize
>> > >>           && (global_options_set.x_flag_tree_loop_vectorize
>> > >>               || global_options_set.x_flag_tree_vectorize)))
>> > >>     return 1;
>> > >>
>> > >> not sure what that was supposed to test.  Jakub?  Similar
>> > >> use in expand_omp_simd.
>> > >
>> > > The intent is/was to check if the vectorizer pass will be invoked,
>> > > otherwise it makes no sense to generate the arrays.
>> > > So, for -O0/-Og or -fno-tree-loop-optimize, we know that the pass
>> > > isn't even in the pipeline.
>> > > And otherwise the intent was that we try to optimize, unless
>> > > user asked explicitly -fno-tree-loop-vectorize or -fno-tree-vectorize
>> > > not to optimize.  Because the vect pass is enabled if:
>> > > flag_tree_loop_vectorize || fun->has_force_vectorize_loops
>> > > but returning non-zero from omp_max_vf and the other omp spot means
>> > > there will be cfun->has_force_vectorize_loops.
>> >
>> > I see.  So it would be good to try if adding EnabledBy(ftree-vectorize) to
>> > ftree-loop-vectorize/ftree-slp-vectorize would add those to global_options_set
>> > iff -ftree-vectorize is enabled (the opts.c hunk setting the flags is then
>> > redundant as well I guess).
>>
>> This looks like it works.
>>
>> I'll prepare the patch and put it through a full bootstrap cycle.
>
> That patch looks like this, and was bootstrapped and tested on
> aarch64-none-linux-gnu with no issues. I've also checked that -ftree-vectorize
> causes -ftree-loop-vectorize and -ftree-slp-vectorize to appear in the verbose
> asm dump as enabled, and that -fprofile-use still correctly turns on
> both of the options. Finally I've checked that -fprofile-use
> -fno-tree-vectorize correctly results in neither of the options being
> enabled.
>
> OK?

Ok.

Thanks,
Richard.

>
> Thanks,
> James
>
> ---
> 2017-07-28  James Greenhalgh  <james.greenhalgh@arm.com>
>
>         * common.opt (ftree-vectorize): No longer set flag_tree_vectorize.
>         (ftree-loop-vectorize): Set as EnabledBy ftree-vectorize.
>         (ftree-slp-vectorize): Likewise.
>         * omp-expand (expand_omp_simd): Remove flag_tree_vectorize, as it
>         can no longer be set independent of flag_tree_loop_vectorize.
>         * omp-general.c (emp_max_vf): Likewise.
>         * opts.c (enable_fdo_optimizations): Remove references to
>         flag_tree_vectorize, these are now implicit.
>         (common_handle_option): Remove handling for OPT_ftree_vectorize,
>         and leave it for the options machinery.
>


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