On Fri, Sep 06, 2024 at 02:10:19PM +0000, Kyrylo Tkachov wrote:
> > This is certainly wrong.
> > PROP_gimple_any is set already at the end of gimplification, so certainly
> > doesn't include any other early gimple passes.
> > And, not all statements are folded during gimplification, e.g. in OpenMP
> > regions folding is postponed until the omp lowering pass and folded only
> > there (at which point PROP_gimple_any is already set).
> >
> > What exactly are you trying to ensure this optimization goes before?
> > For non-VL vectors I guess vector lowering, but that is done far later
> > and we already have a different predicate for that.
> > For VL vectors, what transforms that if user write % ?
>
> There’s currently no way to write this in a generic VLA way. The SVE
> intrinsics for this would be opaque to GIMPLE and the generic vector
> extension doesn’t support VLA for now.
> The problem is the fold-minus-1.c test case that wants to see the fold happen
> early on, and I think that makes sense from a canonicalization POV but when
> the vectorizer has expanded a vector mod later on we don’t want to put it
> back together.
> I agree gimple_any doesn’t look like the right thing. Is there a better check
> to use?
If it never works with SVE or RISC-V VL vectors, then match.pd shouldn't do
it unless it works. Testcase can be always adjusted or limited to targets
which do support that.
Or, do it for VECTOR_INTEGER_TYPE_P only
if ((optimize_vectors_before_lowering_p ()
&& TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
|| target_supports_op_p (type, TRUNC_MOD_EXPR, optab_vector))
i.e. do it before vector lowering for vectors which can be lowered,
and when the optabs works.
Anyway, I think it would be useful to check whether it actually results
in better generated code on targets which support TRUNC_DIV_EXPR
and MULT_EXPR on vectors but not TRUNC_MOD_EXPR (if there are any).
Jakub
