On Thu, 13 May 2021, Kewen.Lin wrote:
> Hi Richi,
>
> Thanks for the review!
>
> on 2021/5/11 下午9:26, Richard Biener wrote:
> > On Fri, 7 May 2021, Kewen.Lin wrote:
> >
> >> Hi,
> >>
> >> This patch is to teach forwprop to optimize some cases where the
> >> permutated operands of vector permutation are from two same type
> >> CTOR and CTOR or one CTOR and one VECTOR CST. It aggressively
> >> takes VIEW_CONVERT_EXPR as trivial copies and transform the vector
> >> permutation into vector CTOR.
> >>
> >> Bootstrapped/regtested on powerpc64le-linux-gnu P9, powerpc64-linux-gnu P8,
> >> x86_64-redhat-linux and aarch64-linux-gnu.
> >>
> >> Is it ok for trunk?
> >
> > Can you please avoid the changes to get_prop_source_stmt and
> > can_propagate_from?
>
> Sure! Do you mean that we need to keep those functions as pure as
> possible? I meant to reuse the single use check in the call.
Yeah, I'd like to get rid of them eventually ...
> > It should work to add a single match
> > of a V_C_E after the get_prop_source_stmt call. Ideally
> > we'd have
> >
> > /* Shuffle of a constructor. */
> > else if (code == CONSTRUCTOR || code == VECTOR_CST)
> > {
> > ...
> > }
> > else if (code == VIEW_CONVERT_EXPR)
> > {
> > op1 must also be a V_C_E or VECTOR_CST here
> > }
> >
> > but then I fear we have no canonicalization of the VECTOR_CST
> > to 2nd VEC_PERM operand. But then moving the op1 gathering
> > out of the if (code == CONSTRUCTOR || code == VECTOR_CST)
> > case (doesn't need an else) might still make such refactoring
> > possible as first matching
> >
> > if (code == VIEW_CONVERT_EXPR || code2 == VIEW_CONVERT_EXPR)
> > {
> > ...
> > }
> > else if (code == CONSTRUCTOR || code == VECTOR_CST)
> > ...
> >
>
>
> The attached patch v2 use the structure by considering the above
> advice and the (code == CONSTRUCTOR || code == VECTOR_CST) part
> can be shared with VIEW_CONVERT_EXPR handlings as below:
>
> op0 gathering (leave V_C_E in code if it's met)
>
> else if (code == CONSTRUCTOR || code == VECTOR_CST || VIEW_CONVERT_EXPR)
> {
> op1 gathering (leave V_C_E in code2)
>
> if (code == VIEW_CONVERT_EXPR || code2 == VIEW_CONVERT_EXPR)
> do the tricks on arg0/arg1/op2
>
> the previous handlings on CONSTRUCTOR/VECTOR_CST
> }
>
> Also updated "shrinked" to "shrunk" as Segher pointed out. :-)
>
> Does it look better now?
Yes. The forwprop changes are OK - I'd still like Richard to
review the vec-perm-indices change.
Thanks, and sorry for the delay,
Richard.
> Bootstrapped/regtested on powerpc64le-linux-gnu P9 btw.
>
> BR,
> Kewen
> -----
> gcc/ChangeLog:
>
> PR tree-optimization/99398
> * tree-ssa-forwprop.c (simplify_permutation): Optimize some cases
> where the fed operands are CTOR/CST and propagated through
> VIEW_CONVERT_EXPR. Call vec_perm_indices::new_shrunk_vector.
> * vec-perm-indices.c (vec_perm_indices::new_shrunk_vector): New
> function.
> * vec-perm-indices.h (vec_perm_indices::new_shrunk_vector): New
> declare.
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/99398
> * gcc.target/powerpc/vec-perm-ctor-run.c: New test.
> * gcc.target/powerpc/vec-perm-ctor.c: New test.
> * gcc.target/powerpc/vec-perm-ctor.h: New test.
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
