From patchwork Wed Jul 4 14:47:20 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Melnik X-Patchwork-Id: 168993 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 AF9F52C0086 for ; Thu, 5 Jul 2012 00:47:59 +1000 (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=1342018080; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=17eHw+KkbWjWEsBIommLrNsgYdY=; b=MkeoMepNOpwDEM2 wdkWbmDcVl0EaDq05yEsvz9q++8KCwlec4AQrmVrtTsEL3k+Hlbj5bpWnU4xx6Wf Y19biJLVArE6ugvpe44wG2I3wn+xIxrx73GvEUHrDmT9Tel8JDnzop3tLzumw2th tj0M1nNHdGaKSykwlcrrabsAKYmA= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=HYM2FCkbzjG+/nFYegDgMNpv2C0tdlaGpzSim+4tgvawayWOpwgB7Roq+2uO9Q 2VzJdWDR60F0Zm1yWuzHXFXlj+BH75B0Pn5Uz3VdidxS2FIlw5VmZACCF26LfhKk Y3hrihYT+7pNbRoeFdTHDVzkKgpH0nj4AZDNdgDPVwUxg=; Received: (qmail 6169 invoked by alias); 4 Jul 2012 14:47:54 -0000 Received: (qmail 6158 invoked by uid 22791); 4 Jul 2012 14:47:52 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.198.202) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jul 2012 14:47:39 +0000 Received: from [10.10.3.58] (winnie.ispras.ru [83.149.198.236]) by smtp.ispras.ru (Postfix) with ESMTP id 054195D4031; Wed, 4 Jul 2012 18:14:46 +0400 (MSD) Message-ID: <4FF45778.3030000@ispras.ru> Date: Wed, 04 Jul 2012 18:47:20 +0400 From: Dmitry Melnik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ramana Radhakrishnan CC: Richard Earnshaw , "gcc-patches@gcc.gnu.org" , Ramana Radhakrishnan , "julian@codesourcery.com" , "jie@codesourcery.com" , "leitz@ispras.ru" , "abel@ispras.ru" Subject: Re: [RFC, ARM] later split of symbol_refs References: <4FEB1F9C.40004@ispras.ru> <4FEB2C87.7070602@arm.com> <4FEDB23E.8070705@ispras.ru> In-Reply-To: X-IsSubscribed: yes 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 On 06/29/2012 06:31 PM, Ramana Radhakrishnan wrote: Ok with this comment? +;; Split symbol_refs at the later stage (after cprop), instead of generating +;; movt/movw pair directly at expand. Otherwise corresponding high_sum +;; and lo_sum would be merged back into memory load at cprop. However, +;; if the default is to prefer movt/movw rather than a load from the constant +;; pool, the performance is usually better. >> +;; Split symbol_refs at the later stage (after cprop), instead of generating >> +;; movt/movw pair directly at expand. Otherwise corresponding high_sum >> +;; and lo_sum would be merged back into memory load at cprop. However, > I would rewrite part of your comment as > >> +;; movt/movw is preferable, because it usually executes faster than a load > "However if the default is to prefer to use movw/movt rather than the > constant pool use that. instead of a load from the constant pool." --- Best regards, Dmitry 2009-05-29 Julian Brown gcc/ * config/arm/arm.md (movsi): Don't split symbol refs here. (define_split): New. --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -5472,14 +5472,6 @@ optimize && can_create_pseudo_p ()); DONE; } - - if (TARGET_USE_MOVT && !target_word_relocations - && GET_CODE (operands[1]) == SYMBOL_REF - && !flag_pic && !arm_tls_referenced_p (operands[1])) - { - arm_emit_movpair (operands[0], operands[1]); - DONE; - } } else /* TARGET_THUMB1... */ { @@ -5588,6 +5580,24 @@ " ) +;; Split symbol_refs at the later stage (after cprop), instead of generating +;; movt/movw pair directly at expand. Otherwise corresponding high_sum +;; and lo_sum would be merged back into memory load at cprop. However, +;; if the default is to prefer movt/movw rather than a load from the constant +;; pool, the performance is usually better. +(define_split + [(set (match_operand:SI 0 "arm_general_register_operand" "") + (match_operand:SI 1 "general_operand" ""))] + "TARGET_32BIT + && TARGET_USE_MOVT && GET_CODE (operands[1]) == SYMBOL_REF + && !flag_pic && !target_word_relocations + && !arm_tls_referenced_p (operands[1])" + [(clobber (const_int 0))] +{ + arm_emit_movpair (operands[0], operands[1]); + DONE; +}) + (define_insn "*thumb1_movsi_insn" [(set (match_operand:SI 0 "nonimmediate_operand" "=l,l,l,l,l,>,l, m,*l*h*k") (match_operand:SI 1 "general_operand" "l, I,J,K,>,l,mi,l,*l*h*k"))]