Re: [patch] Don't insert pattern statements into the code (was Fix PR tree-optimization/49318)

[Richard Guenther <richard.guenther@gmail.com>]

On Tue, Jun 14, 2011 at 12:38 PM, Ira Rosen <ira.rosen@linaro.org> wrote:
> On 14 June 2011 13:02, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Mon, Jun 13, 2011 at 2:43 PM, Ira Rosen <ira.rosen@linaro.org> wrote:
>>> On 10 June 2011 12:14, Richard Guenther <richard.guenther@gmail.com> wrote:
>>>> In the end I think we should not generate the pattern stmt during
>>>> pattern matching but only mark the relevant statements with a
>>>> pattern kind.  Say, for each pattern we have a "main" statement
>>>> that has related stmts belonging to the pattern that define uses
>>>> of the "main" statement - mark those to refer to that "main" statement.
>>>> For that "main" statement simply record an enum value, like,
>>>> widening_mult.  Then only at vectorized statement
>>>> generation time actually generate the vectorized form of the
>>>> pattern statement.
>>>
>>> I ended up with the following: during pattern detection a new scalar
>>> pattern statement is created but not inserted into the code, it is
>>> only recorded as a related statement of the last statement in the
>>> detected pattern. Every time the last statement is being
>>> analyzed/transformed, we switch to the pattern statement instead. It
>>> is much more difficult just to mark the last stmt with an enum value,
>>> since we have to retrieve the relevant operands every time.
>>>
>>> I am not sure if we need to free the pattern stmt at the end.

No, they are going to be garbage collected.

>>> Bootstrapped and now testing on powerpc64-suse-linux (tested
>>> vectorizer testsuite on powerpc64-suse-linux and x86_64-suse-linux.
>>>
>>> What do you think?
>>
>>   /* Mark the stmts that are involved in the pattern. */
>> -  gsi_insert_before (&si, pattern_stmt, GSI_SAME_STMT);
>>   set_vinfo_for_stmt (pattern_stmt,
>>                      new_stmt_vec_info (pattern_stmt, loop_vinfo, NULL));
>> +  gimple_set_bb (pattern_stmt, gimple_bb (stmt));
>>
>> do you really need this?
>
> Yes, there are a lot of uses of gimple_bb (stmt). Otherwise, we'd have
> to check there that bb exists (or that this is not a pattern stmt) and
> use the bb of the original statement if not.

I see.  It's not really uglier than the part where you have to special-case
them when walking use-operands, so ...

Still a lot better than when inserting them for real.

>> Otherwise it looks reasonable.  Btw,
>> we can probably remove the simple DCE done in
>> slpeel_tree_peel_loop_to_edge (remove_dead_stmts_from_loop)
>> with this patch.
>
> I'll try that.

Thanks,
Richard.

> Thanks,
> Ira
>
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> Ira
>>>
>>> ChangeLog:
>>>
>>>     * tree-vect-loop.c (vect_determine_vectorization_factor): Don't
>>>     remove irrelevant pattern statements.  For irrelevant statements
>>>     check if it is the last statement of a detected pattern, use
>>>     corresponding pattern statement instead.
>>>     (destroy_loop_vec_info): No need to remove pattern statements,
>>>     only free stmt_vec_info.
>>>     (vect_transform_loop): For irrelevant statements check if it is
>>>     the last statement of a detected pattern, use corresponding
>>>     pattern statement instead.
>>>     * tree-vect-patterns.c (vect_pattern_recog_1): Don't insert
>>>     pattern statements.  Set basic block for the new statement.
>>>     (vect_pattern_recog): Update documentation.
>>>     * tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized): Scan
>>>     operands of pattern statements.
>>>     (vectorizable_call): Fix printing.  In case of a pattern statement
>>>     use the lhs of the original statement when creating a dummy
>>>     statement to replace the original call.
>>>     (vect_analyze_stmt): For irrelevant statements check if it is
>>>     the last statement of a detected pattern, use corresponding
>>>     pattern statement instead.
>>>     * tree-vect-slp.c (vect_schedule_slp_instance): For pattern
>>>     statements use gsi of the original statement.
>>>
>>
>