From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105888 invoked by alias); 3 Apr 2017 07:20:27 -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 105818 invoked by uid 89); 3 Apr 2017 07:20:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=inspect X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Apr 2017 07:20:25 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E6FF764A61; Mon, 3 Apr 2017 07:20:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E6FF764A61 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E6FF764A61 Received: from tucnak.zalov.cz (ovpn-116-72.ams2.redhat.com [10.36.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6F8867EB61; Mon, 3 Apr 2017 07:20:13 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v337KAjR012724; Mon, 3 Apr 2017 09:20:10 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v337K8lt012723; Mon, 3 Apr 2017 09:20:08 +0200 Date: Mon, 03 Apr 2017 07:20:00 -0000 From: Jakub Jelinek To: Uros Bizjak , "H.J. Lu" Cc: 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: <20170403072008.GC17461@tucnak> Reply-To: Jakub Jelinek References: <20170401122027.GT17461@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00057.txt.bz2 On Sun, Apr 02, 2017 at 08:44:03PM +0200, Uros Bizjak wrote: > x86 part LGTM. > > Hopefully, this infrastructure will allow us to fix (or it already > fixes) PR 56309 [1]. I think only allows to. The target hook has access to the if_info structure which contains the original basic blocks, their edges, frequencies, and can inspect both the new sequence as well as the original basic blocks etc. I really don't know in detail what the problem with cmov is (latency, or that it blocks some CPU units, something else?). In any case, any change will need lots of benchmarking, because apparently cmov is extremely important to get right (for not well predictable branches use it, for other not really). Another question is if say setcc has similar problem or not. > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309 Jakub