From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61428 invoked by alias); 18 Jun 2015 14:17:59 -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 61361 invoked by uid 48); 18 Jun 2015 14:17:52 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else Date: Thu, 18 Jun 2015 14:17:00 -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: 6.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com 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: 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-SW-Source: 2015-06/txt/msg01647.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66588 --- Comment #1 from Uro=C5=A1 Bizjak --- BTW: x86_64 is missing any form of zero-extended cmove. >>From gcc-bugs-return-489314-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 18 14:17:03 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 60431 invoked by alias); 18 Jun 2015 14:17:02 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 60370 invoked by uid 48); 18 Jun 2015 14:16:54 -0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/66565] Problems and limitation GCC cost metrics and ways to improve the situation Date: Thu, 18 Jun 2015 14:17:00 -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: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org 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: bug_status cf_reconfirmed_on cc everconfirmed 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-06/txt/msg01646.txt.bz2 Content-length: 2058 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66565 Eric Botcazou changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2015-06-18 CC| |ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > The proliferation and misunderstanding of cost units is a side effect of > this. So we really have to move to something like: > > target_should_inline_call () > target_should_ifconvert ( transformation>) > target_combine_is_profitable_p () > target_should_reconstruct_value_p ( in registers or reconstruct in loop>) > target_choose_preferred_addressing_mode ( modes for a MEM>) So basically one hook per transformation? And each back-end will have to factorize the common processing? > Where we ask specific and meaningful questions of the target, rather than > asking for a guess at costs and using that. > The difficult argument to make will be that we have to be radical about > this and prepared to regress many targets (in the short term) > for the sake of ending up with a maintainable and understandable design > for making these decisions. We simply cannot do that, there are ~50 architectures in the compilers and this will break them all except for a handful of them. Generally speaking, you cannot reimplement things from scratch in a 25 years old production compiler, you will break far more things than you will ever be able to fix or improve. Either you implement the new scheme in addition to the old one or you fix the old one incrementally, that's pretty much the only practical alternative.