From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63114 invoked by alias); 14 Mar 2016 09:36:45 -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 63054 invoked by uid 89); 14 Mar 2016 09:36:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=describing, selschedirc, insn_t, UD:sel-sched-ir.c X-HELO: mail.ispras.ru Received: from mail.ispras.ru (HELO mail.ispras.ru) (83.149.199.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Mar 2016 09:36:35 +0000 Received: from [10.10.3.52] (pluton2.ispras.ru [83.149.199.44]) by mail.ispras.ru (Postfix) with ESMTPSA id C164D54007B; Mon, 14 Mar 2016 12:36:32 +0300 (MSK) Subject: [03/05] Fix PR 66660 To: GCC Patches References: Cc: Alexander Monakov From: Andrey Belevantsev Message-ID: Date: Mon, 14 Mar 2016 09:36:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------55599BD62BD3CDBF13DC037A" X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00762.txt.bz2 This is a multi-part message in MIME format. --------------55599BD62BD3CDBF13DC037A Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1189 Hello, We speculate an insn in the PR but we do not make a check for it though we should. The thing that broke this was the fix for PR 45472. In that pr, we have moved a volatile insn too far up because we failed to merge the bits describing its volatility when we have processed a control flow split. The code to propagate the insn pattern with the insn merging was added when the volatility of the two insns from the both split branches differ. However, the volatility of the speculated insn and its original differ: the original insn may trap while the speculated version may not. Thus, we replace a speculative pattern with the original one per the PR 45472 fix for no reason. The patch for this problem just limits the original fix for PR 45472 to apply for non-speculative insns only. There is no test as it is not so easy to construct one -- we could count the number of speculation check in the resulting assembly but there is no way to force speculation to happen. Ok for trunk? gcc/ 2016-03-14 Andrey Belevantsev PR target/66660 * sel-sched-ir.c (merge_expr): Do not propagate trap bits into speculative insns. Best, Andrey --------------55599BD62BD3CDBF13DC037A Content-Type: text/x-patch; name="03-pr66660.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="03-pr66660.diff" Content-length: 1303 commit 53ef39496acc26cc0021555e403068e93343aa20 Author: Andrey Belevantsev Date: Wed Jan 27 17:20:27 2016 +0300 Fix pr66660: do not propagate trap bits into speculative insns diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c index e181cb9..ec59280 100644 --- a/gcc/sel-sched-ir.c +++ b/gcc/sel-sched-ir.c @@ -1871,12 +1871,12 @@ merge_expr (expr_t to, expr_t from, insn_t split_point) /* Make sure that speculative pattern is propagated into exprs that have non-speculative one. This will provide us with consistent speculative bits and speculative patterns inside expr. */ - if ((EXPR_SPEC_DONE_DS (from) != 0 - && EXPR_SPEC_DONE_DS (to) == 0) - /* Do likewise for volatile insns, so that we always retain - the may_trap_p bit on the resulting expression. */ - || (VINSN_MAY_TRAP_P (EXPR_VINSN (from)) - && !VINSN_MAY_TRAP_P (EXPR_VINSN (to)))) + if (EXPR_SPEC_DONE_DS (to) == 0 + && (EXPR_SPEC_DONE_DS (from) != 0 + /* Do likewise for volatile insns, so that we always retain + the may_trap_p bit on the resulting expression. */ + || (VINSN_MAY_TRAP_P (EXPR_VINSN (from)) + && !VINSN_MAY_TRAP_P (EXPR_VINSN (to))))) change_vinsn_in_expr (to, EXPR_VINSN (from)); merge_expr_data (to, from, split_point); --------------55599BD62BD3CDBF13DC037A--