This is the mail archive of the
mailing list for the GCC project.
Re: tree if convert pass control
- From: Xinliang David Li <davidxl at google dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Sep 2013 14:07:59 -0700
- Subject: Re: tree if convert pass control
- Authentication-results: sourceware.org; auth=none
- References: <CAAkRFZL=gmygiRtf7YZWyZdi8-FOrVZJQfyC_=RpuK3W=ZxMtA at mail dot gmail dot com> <CAFiYyc3aGWpMiL88e9jb7c19Hmm+OfrDKh+O40w3q963htLkew at mail dot gmail dot com>
Ok -- abandon the patch.
On Mon, Sep 16, 2013 at 2:04 AM, Richard Biener
> On Sat, Sep 14, 2013 at 8:10 AM, Xinliang David Li <firstname.lastname@example.org> wrote:
>> tree if conversion is an enabler pass for vectorization, so by
>> default, it is only turned on when vectorization is on, but may also
>> depend on the optimization level. Currently, the logic to handle this
>> is in the gate function which become hard to understand and extend.
>> The proposed patch move the logic from the gate function to
>> 'finish_option' which is much clearer. The downside of this patch is
>> that function specific optimization node needs to be created for some
>> cases during omp-lowering.
> Something I don't like. What's the issue with checking the
> has_force_vect_loops flag?
> How's the argument that the gate is hard to extend? Wouldn't
> extending it complicate it again and thus make it hard to understand again?
The gating logic is:
1) the pass is a standalone pass that can be turned on independently
of loop vectorizer;
2) the pass can be implicitly turned on by loop vectorizer, and
possibly depending on the optimization level.
The logic is not complicated, but it would be simplier to handle in
the option processing if there was no need for the 'force_vect_loop'
> That said, given that doing things in finish_options () is discouraged
> the patch looks like a step backwards.
Doing it in finish_options can avoid duplicating the handling in
> So, can you explain the underlying rationale?
> Btw, if we think of if-conversion as tied to loop vectorization then we can
> guard it by it and make a new container pass like
> NEXT_PASS (pass_loop_vectorizer);
> PUSH_INSERT_PASSES_WITHIN (pass_loop_vectorizer)
> NEXT_PASS (pass_if_conversion);
> NEXT_PASS (pass_vectorize);
> NEXT_PASS (pass_dce_loop);
> POP_INSERT_PASSES ()
> and guard pass_loop_vectorizer by flag_tree_loop_vectorize, defaulting
> if-conversion to be enabled (but allow disabling it manually).
This will make it hard to turn on the pass independently.
Anyway, there seems no need for the patch.
> Or take the step and move it under control of the vectorizer itself.