From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 709353858D33; Thu, 19 Oct 2023 07:45:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 709353858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1697701506; bh=eaTTCPEq/ZC2XAjLBQO6EYDQtMhKltYOEZb5YNPBPGE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=G+JgNqBgk96zrEoyURgHvILOjFgqxeAA76Eyx02xEbwJYvUPC6FfuaJm++Dov2Y7v hcMmPLGdlgAq/9JRoOia8OuXhOqq7z4doZ7nj+fD7C5F0Q0Wdmjvi11ixzqFYCUZ+3 +k1ygJzf4UB6LzqggngJqjzE/m2mwClzdtuO54fk= From: "juzhe.zhong at rivai dot ai" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111720] RISC-V: Ugly codegen in RVV Date: Thu, 19 Oct 2023 07:45:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: juzhe.zhong at rivai dot ai X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111720 --- Comment #17 from JuzheZhong --- (In reply to Richard Biener from comment #16) > The issue is that we cannot CSE a VLA typed "load" (whatever that is) to a > constnant. >=20 > char arr[] =3D {1, 2, 7, 1, 3, 4, 5, 3, 1 > , 0, 1, 2, 4, 4, 9, 9, 1, 2, 7, 1, 3, 4, 5, 3,=20 > 1, 0, 1, 2, 4, 4, 9, 9}; > char m =3D 1; >=20 > svint8_t varr =3D *(svint8_t*)arr; >=20 > we don't know what portion of 'arr' this accesses. The relevant bit in > vn_reference_lookup_3 would be >=20 > /* 3) Assignment from a constant. We can use folds native encode/inter= pret > routines to extract the assigned bits. */ > else if (known_eq (ref->size, maxsize) > && is_gimple_reg_type (vr->type) > && !reverse_storage_order_for_component_p (vr->operands) > && !contains_storage_order_barrier_p (vr->operands) > && gimple_assign_single_p (def_stmt) > && CHAR_BIT =3D=3D 8 > && BITS_PER_UNIT =3D=3D 8 > && BYTES_BIG_ENDIAN =3D=3D WORDS_BIG_ENDIAN > /* native_encode and native_decode operate on arrays of bytes > and so fundamentally need a compile-time size and offset. = */ > && maxsize.is_constant (&maxsizei) > && offset.is_constant (&offseti) > && (is_gimple_min_invariant (gimple_assign_rhs1 (def_stmt)) > || (TREE_CODE (gimple_assign_rhs1 (def_stmt)) =3D=3D SSA_N= AME > && is_gimple_min_invariant (SSA_VAL (gimple_assign_rhs1 > (def_ >=20 > and we fail at maxsize.is_constant (&maxsizei), that's the actual size of > the load. Maybe there's constraints that are target specific and not > encoded in poly-int that could be used here, but I don't really know. >=20 > So yes, pieces of the compiler are defensive about VLA accesses and > they probably have to be. >=20 > In particular this part of VN doesn't try to use undefinedness (the access > exceeds the size of 'arr') to limit things - but in the end we'd still > need to construct a VLA typed constant and I have no idea how to do that. >=20 > Maybe Richard has an idea. >=20 > Note this has nothing to do about whether we have a CLOBBER or not. You > can "disable" those with -fstack-reuse=3Dnone and that doesn't make a > difference. Thanks Richi. But how about this case in RVV: https://godbolt.org/z/sMYor3arP Use --param=3Driscv-autovec-preference=3Dfixed-vlmax will set the mode as a= known size. This code still have redundant stack transferring load/store.=