On Wed, 18 Sep 2024, Jennifer Schmitz wrote: > > > > 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.
OK. Thanks, Richard. > Best, Jennifer > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
