From patchwork Mon Dec 12 20:10:37 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ramana Radhakrishnan X-Patchwork-Id: 130812 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 53AAB1007D7 for ; Tue, 13 Dec 2011 07:11:05 +1100 (EST) Received: (qmail 28721 invoked by alias); 12 Dec 2011 20:10:55 -0000 Received: (qmail 28708 invoked by uid 22791); 12 Dec 2011 20:10:53 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Dec 2011 20:10:38 +0000 Received: by ggnh1 with SMTP id h1so6173801ggn.20 for ; Mon, 12 Dec 2011 12:10:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.11.104 with SMTP id p8mr3358011obb.24.1323720637130; Mon, 12 Dec 2011 12:10:37 -0800 (PST) Received: by 10.182.235.106 with HTTP; Mon, 12 Dec 2011 12:10:37 -0800 (PST) Date: Mon, 12 Dec 2011 20:10:37 +0000 Message-ID: Subject: [Patch ARM] Fix a latent issue in arm_print_operand From: Ramana Radhakrishnan To: gcc-patches Cc: Patch Tracking , Richard Earnshaw 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, This fixes a latent issue in arm_print_operand where we would have generated a 128 bit alignment hint for any neon instruction that used the %A notation for printing memory addresses. Given that you can never have the load of a 64 bit quantity with an 128 bit alignment (indeed the list of instructions that I could think of that we might generate for this purpose is as below.) vld1.8 d0, [r0] vld1.16 d0, [r0] vld1.32 d0, [r0] vld1.64 d0, [r0] vld2.32 {d0[0], d1[0]}, [r0] vld4.16 {d0[0], d1[0], d2[0], D3[0]}, [r0] This is not an issue today for the following reasons : From the list above: 1. The first 4 instructions will not come out of the compiler today (we put out vldr's or vldmia) instructions for auto-vectorized code. Indeed I found this only when I replaced the vldmia's and the vldr's with vld1's. 2. The last 2 instructions only come out of intrinsics. The first 4 will also get generated with the intrinsics but ..... we get away with this because of the type punning in arm_neon.h Even in the event we use this in that form, I doubt if we'll ever change that situation. I was able to trigger this when I tried to get the backend to generate vld1.64 instructions for appropriate vector modes instead of vldmia / vstmia in little endian configurations. (That will follow once testing completes) Ok ? cheers Ramana 2011-12-08 Ramana Radhakrishnan * config/arm/arm.c (arm_print_operand): Only allow hints of 128 bits for 16 byte loads. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index d1d0c22..bfdac51 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -17654,8 +17654,8 @@ arm_print_operand (FILE *stream, rtx x, int code) /* Only certain alignment specifiers are supported by the hardware. */ if (memsize == 16 && (align % 32) == 0) align_bits = 256; - else if ((memsize == 8 || memsize == 16) && (align % 16) == 0) - align_bits = 128; + else if ((memsize == 16) && (align % 16) == 0) + align_bits = 128; else if ((align % 8) == 0) align_bits = 64; else