From patchwork Fri Dec 24 15:41:16 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ramana Radhakrishnan X-Patchwork-Id: 76632 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 9D8D0B70B8 for ; Sat, 25 Dec 2010 02:41:30 +1100 (EST) Received: (qmail 32324 invoked by alias); 24 Dec 2010 15:41:29 -0000 Received: (qmail 32314 invoked by uid 22791); 24 Dec 2010 15:41:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 24 Dec 2010 15:41:22 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 24 Dec 2010 15:41:18 +0000 Received: from [10.1.66.29] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Dec 2010 15:41:16 +0000 Subject: [Patch] Fix alignment information in RTL for known misaligned addresses. From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@arm.com To: gcc-patches@gcc.gnu.org Cc: rearnsha@arm.com Date: Fri, 24 Dec 2010 15:41:16 +0000 Message-Id: <1293205276.21419.23.camel@e102325-lin.cambridge.arm.com> Mime-Version: 1.0 X-MC-Unique: 110122415411800701 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 Hi, We've been investigating a few failures in the regression testsuite with Neon enabled and these show up here. http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg02072.html One of the failures is with the builtins test for memcpy. memcpy is called with the following values. (dst=0x15360, src=0xbb7c, n=17) It ends up with a bus error on a Cortex A9 because we have a vld1.8 instruction with an alignment specifier of 64 bits and the address we pass (src) in this case is not 64 bit aligned. The alignment specifiers are supposed to be hints to the memory system to accelerate memory accesses. If the address is not aligned as per the alignment specifier i.e. you've specified more alignment than you actually have in the base address the hardware will cause an unaligned access abort. Thus it's important for the compiler to track alignment information correctly. This attached patch by Richard attempts to fix this by setting the correct alignment to the generated memory rtx before the generation of the call to movmisalign_optab. By default the memory alignment is set to be the natural alignment of the type rather than what the alignment was set up to be at the gimple level. This fixes all the failures with respect to builtins.exp that were observed in the test report and fixes runs for a number of benchmarks that were failing with Neon turned on at O3. A full bootstrap and test for armv7-a , neon and softfp is on currently. Ok to commit if no regressions ? cheers Ramana Richard Earnshaw * expr.c (expand_assignment): Set MEM_ALIGN correctly for misaligned accesses. (expand_expr_real_1): Likewise. *** expr.c (revision 168190) --- expr.c (local) *************** expand_assignment (tree to, tree from, b *** 4191,4196 **** --- 4191,4201 ---- && op_mode1 != VOIDmode) reg = copy_to_mode_reg (op_mode1, reg); + /* The aligment on the memory is currently the natural alignment + for the type, not that for an unaligned load, so force it + down to the known alignment. */ + set_mem_align (mem, align); + insn = GEN_FCN (icode) (mem, reg); /* The movmisalign pattern cannot fail, else the assignment would silently be omitted. */ *************** expand_expr_real_1 (tree exp, rtx target *** 8656,8661 **** --- 8661,8671 ---- { rtx reg, insn; + /* The aligment on the memory is currently the natural + alignment for the type, not that for an unaligned load, + so force it down to the known alignment. */ + set_mem_align (temp, align); + /* We've already validated the memory, and we're creating a new pseudo destination. The predicates really can't fail. */ reg = gen_reg_rtx (mode); *************** expand_expr_real_1 (tree exp, rtx target *** 8753,8758 **** --- 8763,8773 ---- { rtx reg, insn; + /* The aligment on the memory is currently the natural + alignment for the type, not that for an unaligned load, + so force it down to the known alignment. */ + set_mem_align (temp, align); + /* We've already validated the memory, and we're creating a new pseudo destination. The predicates really can't fail. */ reg = gen_reg_rtx (mode);