[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
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: <gcc-bugs-return-489314-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-66565-4-BGm8Ciws8L@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66565-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66565-4@http.gcc.gnu.org/bugzilla/>
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?idf565

Eric Botcazou <ebotcazou at gcc dot gnu.org> 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 <ebotcazou at gcc dot gnu.org> ---
>   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 (<interesting call information from the pass>)
>   target_should_ifconvert (<gimple sequences for before/after
> transformation>)
>   target_combine_is_profitable_p (<before, after rtx>)
>   target_should_reconstruct_value_p (<candidate RTX to either build and keep
> in registers or reconstruct in loop>)
>   target_choose_preferred_addressing_mode (<list of candidate addressing
> 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.