From patchwork Wed Sep 5 11:42:40 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Gretton-Dann X-Patchwork-Id: 181850 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 7DE0D2C008C for ; Wed, 5 Sep 2012 21:43:02 +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=1347450183; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Cc:Subject:Date:Message-ID:User-Agent: MIME-Version:Content-Transfer-Encoding:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=bwATThh+H8dyR4d7xUOxnDySj3g=; b=Zalh4zQTS16XcARUsncjP8PzRwjqIbgtP8VHzJsCDwUUzy/C3c1+b2n44wC6/h /XL7hZkNHQDgyj01QhUhwutMk+eudguadHNqxx7vDO+OBKpl7OfZ3gD0b+9yonV9 IvekAQ/YHdONJvCnyz4HSBBmk8p1uj9ngxcTzq7yL1mpU= 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:X-Google-DKIM-Signature:Received:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Transfer-Encoding:Content-Type:X-Gm-Message-State:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=yfatFLLrCmH8CdZlkhpP7U6/j6m9NZpzEMBbPNw2m1TX5E0aX8J6ZCTLD7MS24 vH82l9APNqsbODNxcqoP6wjwMRKwzxkDqew7/njJHfytGjSOhkT+pxwx4Xt6+VE3 BWBRVHcmXTuyiYY13hbkDQ+DxpC7DwSEZas2SZI2fEoBk=; Received: (qmail 6022 invoked by alias); 5 Sep 2012 11:42:58 -0000 Received: (qmail 6005 invoked by uid 22791); 5 Sep 2012 11:42:57 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Sep 2012 11:42:44 +0000 Received: by wgbds1 with SMTP id ds1so4128616wgb.2 for ; Wed, 05 Sep 2012 04:42:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type:x-gm-message-state; bh=r6HFHpD3rdU80eBXT/QgsCA2+NghFnEpdOSlHnShp7s=; b=ApLwSrlaR+UA4MWkMg//bJcjRB4/Fkyizmyyesjt5u4idl7xTttY11R72f3S5S/PAv n7CrY+azvGR/8awgr/FXazRlw3hN8yts/0vyhu3qCMRFMm5mAmBfMviOJAWah+WiFJo7 AD5RZUGB8Q+bmAgf7FCBz2wHcv2/m8kQ5iVEeyzxTrSkER2mqaGv1IGYy0D13FFYQbBh YOw6BwXusqay/DzteX9mea20zE3+sf8YzSPaZ9xobK/KHbRZYMHG+zGYgpZLH3CM2VE/ l+r6kRKReVGp9rNVVVFc2GvTTuuhuNQn9DYd8IGb8UhAIn1ou0T18bMoZWWnaqqAVMWE RFXQ== Received: by 10.180.95.193 with SMTP id dm1mr37642335wib.10.1346845362892; Wed, 05 Sep 2012 04:42:42 -0700 (PDT) Received: from e103209-lin.localnet ([146.90.135.135]) by mx.google.com with ESMTPS id b7sm4058432wiz.9.2012.09.05.04.42.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 04:42:42 -0700 (PDT) From: Matthew Gretton-Dann To: gcc-patches@gcc.gnu.org Cc: jle@rice.edu, rearnsha@arm.com, ramrad01@arm.com, law@redhat.com, ebotcazou@libertysurf.fr, rdsandiford@googlemail.com Subject: [RFA 2/n] Don't lift loads above register using jumps in postreload-gcse.c Date: Wed, 05 Sep 2012 12:42:40 +0100 Message-ID: <1721935.92zzXaUnD9@e103209-lin> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQnvyM/Rb+oBaZk9XQ8Ek6rz+B2xuusueX5WIVdEsqoKvDa9UARLnXANSmP/HP5ivGtIZM9N 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 All, When implementing ARM/Thumb support for -freorder-blocks-and-partition I encountered the following silent code generation fault. Given the following CFG: | | 93 97 | | (FALLTHRU) (CROSSING) \ / \----\ /---/ \/ 94 | Basic Block 94 has the following insn in it which we want to lift into blocks 93 and 97: (insn/v 62 767 63 94 (set (reg:SI 3 r3 [orig:1468 ivtmp.85 ] [1468]) (mem/c:SI (plus:SI (reg/f:SI 13 sp) (const_int 20 [0x14])) [7 %sfp+-52 S4 A32])) For block 93 this becomes a move from r0 to r3 - and everything is OK. For block 97 there is no appropriate move so the compiler tries to copy the load, and insert it on the edge from 97 to 94. This edge is a crossing edge, and so is implemented by an indirect jump: (insn 2795 2590 3940 97 (set (reg:SI 3 r3 [2464]) (mem/u/c:SI (symbol_ref/u:SI ("*.LC19") [flags 0x2]) [2 S4 A32])) 634 {*arm_movsi_vfp} (insn_list:REG_LABEL_OPERAND 887 (expr_list:REG_EQUIV (label_ref:SI 887) (nil)))) (jump_insn 2796 3940 2593 97 (set (pc) (reg:SI 3 r3 [2464])) 264 {*arm_indirect_jump} (expr_list:REG_CROSSING_JUMP (nil) (nil))) The compiler tries to insert the copy of insn 62 (in this case it becomes insn 3940) immediately before the jump_insn - which because this is a crossing edge is implemented as an indirect jump using a register in the ARM backend: (insn 2795 2590 3940 97 (set (reg:SI 3 r3 [2464]) (mem/u/c:SI (symbol_ref/u:SI ("*.LC19") [flags 0x2]) [2 S4 A32])) 634 {*arm_movsi_vfp} (insn_list:REG_LABEL_OPERAND 887 (expr_list:REG_EQUIV (label_ref:SI 887) (nil)))) (insn 3940 2795 2796 97 (set (reg:SI 3 r3 [orig:1468 ivtmp.85 ] [1468]) (mem/c:SI (plus:SI (reg/f:SI 13 sp) (const_int 20 [0x14])) [7 %sfp+-52 S4 A32])) -1 (nil)) (jump_insn 2796 3940 2593 97 (set (pc) (reg:SI 3 r3 [2464])) 264 {*arm_indirect_jump} (expr_list:REG_CROSSING_JUMP (nil) (nil))) However, this is incorrect as insn 3940 sets r3, and the jump_insn 2796 wants to use r3 (as set by 2795). The patch fixes this by checking that the register set by the load is not used by the jump before allowing the load to be lifted. Whilst this fix works for this particular case I am not sure it is the best fix for the general issue, and so if others have a better idea how to fix this I would be very happy. In particular I wonder whether we should be defining TARGET_CANNOT_MODIFY_JUMPS_P for the ARM backend as indirect jumps use registers in a similar way to the SH backend. Not that this would have helped in this particular instance. Tested cross arm-linux-none-gnueabi with in progress ARM -freorder-blocks-and- partition enabling patch. OK? Thanks, Matt gcc/ChangeLog: 2012-09-05 Matthew Gretton-Dann * postreload-gcse.c (eliminate_partially_redundant_load): Ensure that loads are not lifted over branches which use the register loaded. diff --git a/gcc/postreload-gcse.c b/gcc/postreload-gcse.c index b464d1f..85fb9b3 100644 --- a/gcc/postreload-gcse.c +++ b/gcc/postreload-gcse.c @@ -1048,6 +1048,13 @@ eliminate_partially_redundant_load (basic_block bb, rtx /* Adding a load on a critical edge will cause a split. */ if (EDGE_CRITICAL_P (pred)) critical_edge_split = true; + + /* If the destination register is used at the BB end we can not + insert the load. */ + if (reg_used_between_p (dest, PREV_INSN (BB_END (pred_bb)), + next_pred_bb_end)) + goto cleanup; + not_ok_count += pred->count; unoccr = (struct unoccr *) obstack_alloc (&unoccr_obstack, sizeof (struct unoccr));