From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2B6813858426; Thu, 24 Aug 2023 09:29:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2B6813858426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1692869344; bh=7Et9Ndw+UJY+Js1zGkOIPejMYYr+FqGs/eRKCcIUjAw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JMdK2cop57dZO+RXUehl/us8eJpH+ZRSW6NYg2W1WblrwoIi+hOKDhUUqLOcfr8IV OJavwr5zdi6KiFpmYAv1ukFh9H1I726Epwq4lXQ7ZWDRPNWFzvaAfb5DvylmXjeRl6 XKq++cFbf6OScslYwSxlonlKB8xf/COxepvlph1E= From: "rdapp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/108412] RISC-V: Negative optimization of GCSE && LOOP INVARIANTS Date: Thu, 24 Aug 2023 09:28:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rdapp at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: cc 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=3D108412 Robin Dapp changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rdapp at gcc dot gnu.org --- Comment #3 from Robin Dapp --- I played around a bit with the scheduling model and the pressure-aware scheduling. -fsched-pressure alone does not seem to help because the probl= em is indeed the latency of vector load and store. The scheduler will try to = keep dependent loads and stores apart (for the number of cycles specified), and then, after realizing there is nothing to put in between, lump everything together at the end of the sequence. That's a well known but unfortunate property of scheduling. Will need to think of something but not resolved for now.=