From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129225 invoked by alias); 1 Apr 2017 18:43:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 129210 invoked by uid 89); 1 Apr 2017 18:43:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Apr 2017 18:43:38 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v31Iha9E006826; Sat, 1 Apr 2017 13:43:37 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v31IhagL006825; Sat, 1 Apr 2017 13:43:36 -0500 Date: Sat, 01 Apr 2017 18:43:00 -0000 From: Segher Boessenkool To: Jakub Jelinek Cc: Uros Bizjak , Jeff Law , Bernd Schmidt , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] On x86 allow if-conversion of more than one insn as long as there is at most one cmov (PR tree-optimization/79390) Message-ID: <20170401184335.GE4402@gate.crashing.org> References: <20170401122027.GT17461@tucnak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170401122027.GT17461@tucnak> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00023.txt.bz2 Hi, On Sat, Apr 01, 2017 at 02:20:27PM +0200, Jakub Jelinek wrote: > As discussed in the PR, in the following testcase we don't if-convert > with the generic (and many other) tuning, because we default to > --param max-rtl-if-conversion-insns=1 in most of the tunings. > The problem we have is with multiple cmov instructions, but in the > testcase there is just one cmov and the other insn is turned into a SSE > max insn, which is fine. > > This patch stops artificially lowering that param, and for one_if_conv_insn > tuning it instead rejects the if-conversion if the resulting sequence has > multiple cmov instructions. The hook is passed if_info too, so it can > in the future do better heuristics based on predictability of the edges, > how far the uses of the cmov result are (I assume cmov major problem is > latency, right?) etc. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Does this change anything for targets that do not implement the new hook? It isn't immediately obvious from the patch. Segher