From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70544 invoked by alias); 19 Oct 2015 16:06:29 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 70486 invoked by uid 48); 19 Oct 2015 16:06:25 -0000 From: "ktkachov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/67635] [SH] ifcvt missed optimization Date: Mon, 19 Oct 2015 16:06:00 -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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ktkachov 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg01504.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67635 ktkachov at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- I had a look at: unsigned int test_03 (unsigned int x) { return x > 0 ? x + 1 : x; } The cse1 pass transforms this into something not quite comfortable for ifcvt. Basically, it transforms the RTL equivalent of: compare (x, 0); if (x > 0) temp := x + 1; else temp := x; return temp; into: compare (x, 0); if (x > 0) temp := x + 1; else temp := 0; return temp; which is a valid transformation to make as far as cse is concerned. Unfortunately, when ifcvt comes along, it's asked to optimise a conditional select between '0' and 'x + 1', which is not something it can do with an addc-style pattern. I initially thought of looking into the condition to see if it contains x (so that we can deduce that the 'else' arm could actually be replaced with x, undoing the cse in that case), but the condition rtl contains a comparison with the T-register, rather than the original comparison with 0. Perhaps we can consider teaching cse to not transform these kinds of expressions (c ? x : x + a) if the target has a store_flag/addcc instruction of the appropriate mode? But I'm not familiar with the cse code, so I don't know how easy/clean that is