From patchwork Tue Feb 28 01:30:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Jambor X-Patchwork-Id: 143308 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 49276B6FA5 for ; Tue, 28 Feb 2012 12:42:16 +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=1330998136; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Resent-From:Resent-Date:Resent-Message-ID:Resent-To:Message-Id: User-Agent:Date:From:To:Cc:Subject:References: Content-Disposition:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=LuvPPsNcWyKYkNc2XdBaiYGmR0E=; b=cjWEJSxgNU1HaGG a42TNLbj6Dhdc/9UsXksDSFCiGzgPZOPoU307et1qh6q0+pEOw0aMMhmcDKzQVb/ wAePEVeNK36nPPN5G0CK40bQpGbyFBp25mbTboyAyIpR9LuY0lQ/Tk98Akov3yid lMz4WVbi6ww6qNF3rNuoVmXc0sdo= 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:Resent-From:Resent-Date:Resent-Message-ID:Resent-To:Message-Id:User-Agent:Date:From:To:Cc:Subject:References:Content-Disposition:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=h7DiGoFmcZ9Re1UQw1Kp7kZAy6IKeeCQhf+btAOBDjVyWUYDomfbekk426IBRA 1gKcS45wtvH6Z82b36U8jFtpZmJxj/1c7vmg48dgLAG83KqnAf7zOUCnt01Xc3iO n0jbIoHHHOInOD9CHovzQg0g6pcFUZLXiubiR8154oX4M=; Received: (qmail 31011 invoked by alias); 28 Feb 2012 01:42:05 -0000 Received: (qmail 30993 invoked by uid 22791); 28 Feb 2012 01:42:04 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Feb 2012 01:41:38 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id EAD1D90983 for ; Tue, 28 Feb 2012 02:41:36 +0100 (CET) Resent-From: Martin Jambor Resent-Date: Tue, 28 Feb 2012 02:41:36 +0100 Resent-Message-ID: <20120228014136.GD28977@virgil.arch.suse.de> Resent-To: GCC Patches Message-Id: <20120228013439.928604285@virgil.suse.cz> User-Agent: quilt/0.48-20.3.1 Date: Tue, 28 Feb 2012 02:30:39 +0100 From: Martin Jambor To: GCC Patches Cc: Richard Guenther Subject: [RFC PATCH 3/3] Misaligned MEM_REF reads References: <20120228013036.494202900@virgil.suse.cz> Content-Disposition: inline; filename=misaligned_read.diff 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 patch fixes misaligned reads through MEM_REFs such as the one in the testcase which currently fails on both sparc64 and ia64 (again, the array and the loop are there to cross ia64 cache line and fail there too). The patch has to be applied last in the series so that the current LHS expansion does not attempt to use the new code. The mechanism is again very similar, except that we call extract_bit_field instead now. We do not need to care about the mem_ref_refers_to_non_mem_p case because that is already handled at this stage. On the other hand, messing with complex types actually breaks currently working testcases such as the one from the previous patch (I have not really fully investigated what goes on so far but it genuinely seems to work) so again I punt for complex modes. There are two more movmisalign_optab generations in this function. There is the TARGET_MEM_REF case which I intend to piggy-back on in the same way like MEM_REF is handled in this patch once it leaves the RFC stage. Finally, movmisalign_optab is also generated in VIEW_CONVERT_EXPR case but as far as I understand the code, misaligned loads are already handled there (only perhaps we should use SLOW_UNALIGNED_ACCESS instead of STRICT_ALIGNMENT there?). Thanks, Martin 2012-02-28 Martin Jambor * expr.c (expand_expr_real_1): handle misaligned scalar reads from memory through MEM_REFs by calling extract_bit_field. * testsuite/gcc.dg/misaligned-expand-1.c: New test. Index: src/gcc/expr.c =================================================================== --- src.orig/gcc/expr.c +++ src/gcc/expr.c @@ -9453,21 +9453,29 @@ expand_expr_real_1 (tree exp, rtx target if (TREE_THIS_VOLATILE (exp)) MEM_VOLATILE_P (temp) = 1; if (mode != BLKmode - && align < GET_MODE_ALIGNMENT (mode) - /* If the target does not have special handling for unaligned - loads of mode then it can use regular moves for them. */ - && ((icode = optab_handler (movmisalign_optab, mode)) - != CODE_FOR_nothing)) + && !COMPLEX_MODE_P (mode) + && align < GET_MODE_ALIGNMENT (mode)) { - struct expand_operand ops[2]; + if ((icode = optab_handler (movmisalign_optab, mode)) + != CODE_FOR_nothing) + { + struct expand_operand ops[2]; - /* We've already validated the memory, and we're creating a - new pseudo destination. The predicates really can't fail, - nor can the generator. */ - create_output_operand (&ops[0], NULL_RTX, mode); - create_fixed_operand (&ops[1], temp); - expand_insn (icode, 2, ops); - return ops[0].value; + /* We've already validated the memory, and we're creating a + new pseudo destination. The predicates really can't fail, + nor can the generator. */ + create_output_operand (&ops[0], NULL_RTX, mode); + create_fixed_operand (&ops[1], temp); + expand_insn (icode, 2, ops); + return ops[0].value; + } + else if (!COMPLEX_MODE_P (mode) + && SLOW_UNALIGNED_ACCESS (mode, align)) + temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode), + 0, TYPE_UNSIGNED (TREE_TYPE (exp)), true, + (modifier == EXPAND_STACK_PARM + ? NULL_RTX : target), + mode, mode); } return temp; } Index: src/gcc/testsuite/gcc.dg/misaligned-expand-1.c =================================================================== --- /dev/null +++ src/gcc/testsuite/gcc.dg/misaligned-expand-1.c @@ -0,0 +1,41 @@ +/* Test that expand can generate correct loads of misaligned data even on + strict alignment platforms. */ + +/* { dg-do run } */ +/* { dg-options "-O0" } */ + +extern void abort (); + +typedef unsigned int myint __attribute__((aligned(1))); + +unsigned int +foo (myint *p) +{ + return *p; +} + +#define cst 0xdeadbeef +#define NUM 8 + +struct blah +{ + char c; + myint i[NUM]; +}; + +struct blah g; + +int +main (int argc, char **argv) +{ + int i, k; + for (k = 0; k < NUM; k++) + { + g.i[k] = cst; + i = foo (&g.i[k]); + + if (i != cst) + abort (); + } + return 0; +}