From patchwork Mon Feb 18 18:46:06 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greta Yorsh X-Patchwork-Id: 221448 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 827B92C008C for ; Tue, 19 Feb 2013 05:46:42 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1361818003; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=w2Pab1I2NgKFYab9I8vUzS2xkfY=; b=ZKHJdhw2vaZmAOH fqkMbPHCUAdSXclaTk0itYZulQmfm4eroWWUQBdk1CMhzaYRAgxJcULKODqxsSUX n5wbiPJsVIi72xQR4iJA6+u7V9+0JSWjk1qZP1qiS3LxEClzxrf7GZboT/zIsH5s MvXO0vkxB1w/GB6p+S8SuPfhY63s= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:X-MC-Unique:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=nW+mMmPfYL+p9Mr50sRJ7a4zLvUnshkWXt6W+DQtGWXi30UZTvahv2kRvVKgE/ YPlEwyWFI9nBTc+wAoGZk0kHbZuVv0w7D1DA+FkJM+ZmsfKpfqtqLfFIKfqQ/tbK 8WPZ6fNs0RKqksfq/VFhPP3ixyfDXpt8lXO9fGHYmW26w=; Received: (qmail 13732 invoked by alias); 18 Feb 2013 18:46:36 -0000 Received: (qmail 13699 invoked by uid 22791); 18 Feb 2013 18:46:34 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, KHOP_THREADED, MSGID_MULTIPLE_AT, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Feb 2013 18:46:14 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 18 Feb 2013 18:46:13 +0000 Received: from e103227vm ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Feb 2013 18:46:10 +0000 From: "Greta Yorsh" To: "Greta Yorsh" , "GCC Patches" Cc: "Richard Earnshaw" , "Ramana Radhakrishnan" , , References: <001101ce0e05$f5928a50$e0b79ef0$@yorsh@arm.com> In-Reply-To: <001101ce0e05$f5928a50$e0b79ef0$@yorsh@arm.com> Subject: [PATCH, ARM][7/n] Comment on splitting THUMB1 patterns Date: Mon, 18 Feb 2013 18:46:06 -0000 Message-ID: <002b01ce0e08$364fa6c0$a2eef440$@yorsh@arm.com> MIME-Version: 1.0 X-MC-Unique: 113021818461300201 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This patch adds a comment explaining why it is difficult to split Thumb1 patterns. gcc/ 2013-02-12 Greta Yorsh * config/arm/arm.md: Comment on splitting Thumb1 patterns. diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 64888f9..ce98013 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -22,6 +22,25 @@ ;;- See file "rtl.def" for documentation on define_insn, match_*, et. al. +;; Beware of splitting Thumb1 patterns that output multiple +;; assembly instructions, in particular instruction such as SBC and +;; ADC which consume flags. For example, in the pattern thumb_subdi3 +;; below, the output SUB implicitly sets the flags (assembled to SUBS) +;; and then the Carry flag is used by SBC to compute the correct +;; result. If we split thumb_subdi3 pattern into two separate RTL +;; insns (using define_insn_and_split), the scheduler might place +;; other RTL insns between SUB and SBC, possibly modifying the Carry +;; flag used by SBC. This might happen because most Thumb1 patterns +;; for flag-setting instructions do not have explicit RTL for setting +;; or clobbering the flags. Instead, they have the attribute "conds" +;; with value "set" or "clob". However, this attribute is not used to +;; identify dependencies and therefore the scheduler might reorder +;; these instruction. Currenly, this problem cannot happen because +;; there are no separate Thumb1 patterns for individual instruction +;; that consume flags (except conditional execution, which is treated +;; differently). In particular there is no Thumb1 armv6-m pattern for +;; sbc or adc. + ;;--------------------------------------------------------------------------- ;; Constants