From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 540 invoked by alias); 5 Jul 2012 08:32:11 -0000 Received: (qmail 524 invoked by uid 22791); 5 Jul 2012 08:32:10 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_FW X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jul 2012 08:31:56 +0000 From: "zhenqiang.chen at linaro dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/53861] New: Assignment of an array element from pointer is not taken as ARRAY_TYPE when expand_assignment Date: Thu, 05 Jul 2012 08:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: zhenqiang.chen at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-07/txt/msg00503.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53861 Bug #: 53861 Summary: Assignment of an array element from pointer is not taken as ARRAY_TYPE when expand_assignment Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: zhenqiang.chen@linaro.org In expr.c, there are comments and codes in function expand_assignment. /* Assignment of a structure component needs special treatment if the structure component's rtx is not simply a MEM. Assignment of an array element at a constant index, and assignment of an array element in an unaligned packed structure field, has the same problem. Same for (partially) storing into a non-memory object. */ if (handled_component_p (to) || (TREE_CODE (to) == MEM_REF && mem_ref_refers_to_non_mem_p (to)) || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE) But if an array element is accessed from a pointer, the condition check will fail. Here is an example: void test1( unsigned char* t, unsigned char* t1); void test (int i, int j) { unsigned char *p; unsigned char a1[16]; unsigned char a[8]; p = &a; p[1] = 1; p[3] = 3; a1[2] = 6; test1(a, a1); } Compile it with -O2/Os. The t.c.149t.optimized is like: ;; Function test (test, funcdef_no=0, decl_uid=4059, cgraph_uid=0) test (int i, int j) { unsigned char a[8]; unsigned char a1[16]; : MEM[(unsigned char *)&a + 1B] = 1; MEM[(unsigned char *)&a + 3B] = 3; a1[2] = 6; test1 (&a, &a1); a1 ={v} {CLOBBER}; a ={v} {CLOBBER}; return; } The MEM_REF is not taken as an array element access. Then their address will be simplified based on the sp during expanding. But in some targets (like ARM THUMB1), sp can not be used in some sore instructions, we have to reset the base address from sp before each reference. If we take the MEM_REF as ARRAY_TYPE (by tracing its operand's TREE_TYPE, we can find it is from ARRAY_TYPE), we can keep the index mode during expanding. After that, if the targets support sp used in store instructions (like X86, MIPS, ARM THUMB2 etc), fwprop1 can optimized it. Otherwise, just keep the index mode, then we need only set the base address once.