From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4814A3857C4D; Wed, 19 Jan 2022 07:27:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4814A3857C4D From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526 Date: Wed, 19 Jan 2022 07:27:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 07:27:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102860 --- Comment #9 from rguenther at suse dot de --- On Tue, 18 Jan 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102860 >=20 > Jakub Jelinek changed: >=20 > What |Removed |Added > -------------------------------------------------------------------------= --- > CC| |jakub at gcc dot gnu.org >=20 > --- Comment #7 from Jakub Jelinek --- > Short testcase: > function foo(a) > integer(kind=3D4) :: a(1024) > a(:) =3D modulo (a(:), 39) > end function > -O2 -mcpu=3Dpower10. > vect_recog_divmod_pattern only handles TRUNC_{DIV,MOD}_EXPR and EXACT_DIV= _EXPR > (and isn't guaranteed to succeed anyway), but optab_for_tree_code returns= the > same smod_optab or sdiv_optab (if signed; FLOOR_* for unsigned is mapped = to > TRUNC_*). > I guess the quickest way would be to punt on {CEIL,FLOOR,ROUND}_{DIV,MOD}= _EXPR > in the vectorizer and tree-vect-generic.cc True. > Further gradual improvements can be: > 1) match.pd has: > /* For unsigned integral types, FLOOR_DIV_EXPR is the same as > TRUNC_DIV_EXPR. Rewrite into the latter in this case. */ > (simplify > (floor_div @0 @1) > (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type)) > && TYPE_UNSIGNED (type)) > (trunc_div @0 @1))) > but expmed.cc has: > /* Promote floor rounding to trunc rounding for unsigned operations. */ > if (unsignedp) > { > if (code =3D=3D FLOOR_DIV_EXPR) > code =3D TRUNC_DIV_EXPR; > if (code =3D=3D FLOOR_MOD_EXPR) > code =3D TRUNC_MOD_EXPR; > if (code =3D=3D EXACT_DIV_EXPR && op1_is_pow2) > code =3D TRUNC_DIV_EXPR; > } > Shouldn't we make it > (for floor_divmod (floor_div floor_mod) > trunc_divmod (trunc_div trunc_mod) > (simplify > (floor_divmod @0 @1) > (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type)) > && TYPE_UNSIGNED (type)) > (trunc_divmod @0 @1)))) > ? Yeah, if the simplification is incomplete we should amend it. > 2) as the RTL optabs really do just trunc div/mod, perhaps > tree-vect-patterns.cc > could be changed to replace some or all of those operations with the trunc > operation followed by some arith and cond_exprs so that the vectorizer kn= ows > actual cost of those operations. > E.g. it seems expmed.cc expands > r =3D x %[fl] y; > as > r =3D x % y; if (r && (x ^ y) < 0) r +=3D y; > and > d =3D x /[fl] y; > would be > r =3D x % y; d =3D x / y; if (r && (x ^ y) < 0) --d; > Looking at wide-int.h, > r =3D x %[cl] y; > as > r =3D x % y; if (r && (x ^ y) >=3D 0) r -=3D y; > and > d =3D /[cl] y; > as > r =3D x % y; d =3D x / y; if (r && (x ^ y) >=3D 0) ++d; > All of the above for signed, as I said earlier, unsigned [fl] is the same= as > trunc and unsigned [cl] should replace (x ^ y) >=3D 0 with 1. > [rd] is even more complex. That sounds reasonable as well. I think we can do 0) and 1) now and defer 2) to the next stage1, maybe tracking it with an enhancement bugreport.=