> On 6 Sep 2024, at 16:20, Jakub Jelinek <ja...@redhat.com> wrote: > > External email: Use caution opening links or attachments > > > 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). Hi Jakub, Thanks, your suggestion works well: The test case from the bug report no longer ICEs and fold-minus-1.c also passes. I bootstrapped and regtested the updated patch on aarch64-linux-gnu and x86_64-linux-gnu, no regression. Best, Jennifer
0001-PR116569-match.pd-Check-trunc_mod-vector-obtap-befor.patch
Description: Binary data
> > Jakub >
smime.p7s
Description: S/MIME cryptographic signature
