From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2983 invoked by alias); 30 Jun 2014 06:17:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 2958 invoked by uid 89); 30 Jun 2014 06:17:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f169.google.com Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 30 Jun 2014 06:17:27 +0000 Received: by mail-ie0-f169.google.com with SMTP id at1so6639120iec.28 for ; Sun, 29 Jun 2014 23:17:25 -0700 (PDT) X-Received: by 10.42.51.204 with SMTP id f12mr36713089icg.21.1404109045628; Sun, 29 Jun 2014 23:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.117.101 with HTTP; Sun, 29 Jun 2014 23:17:05 -0700 (PDT) In-Reply-To: <20140628001430.GA17229@kam.mff.cuni.cz> References: <53AB38AB.7040901@redhat.com> <53ADF18E.9090404@redhat.com> <20140628001430.GA17229@kam.mff.cuni.cz> From: Kito Cheng Date: Mon, 30 Jun 2014 06:17:00 -0000 Message-ID: Subject: Re: [PATCH] Pass correct memory attributes for build constant To: Jan Hubicka Cc: Jeff Law , gcc-patches@gcc.gnu.org, Richard Sandiford , Eric Botcazou , Ramana Radhakrishnan Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg02365.txt.bz2 >>test.c: >>extern bar(unsigned char p[3][2]); >>void foo(int i) >>{ >> unsigned char data[3][2] = {{1,1}, {1,0}, {1,1}}; >> >> bar(data); >>} > First, note, I'm not an ARM expert. However, the first question I > have is are we sure the initializer is always going to be suitably > aligned? What guarantees this initializer is going to have 32 bit It's a ARRAY_TYPE for the data and ARM require 32-bit align for that. (Aligned by DATA_ALIGNMENT as Jan say.) > I think that needs to be settled first, then we need to verify that > the trees are correctly carrying that alignment requirement around > and that the code uses it appropriately (and I have my doubts > because EXP is a CONSTRUCTOR element and those seem to be largely > ignored in the code we're looking to change). The key problem is `exp` don't have right alignment info, but `decl` have, we can observe this in the code: varasm.c 3166 /* Construct the VAR_DECL associated with the constant. */ 3167 decl = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier (label), 3168 TREE_TYPE (exp)); 3169 DECL_ARTIFICIAL (decl) = 1; 3170 DECL_IGNORED_P (decl) = 1; 3171 TREE_READONLY (decl) = 1; 3172 TREE_STATIC (decl) = 1; 3173 TREE_ADDRESSABLE (decl) = 1; ... 3181 if (TREE_CODE (exp) == STRING_CST) 3182 { 3183 #ifdef CONSTANT_ALIGNMENT 3184 DECL_ALIGN (decl) = CONSTANT_ALIGNMENT (exp, DECL_ALIGN (decl)); 3185 #endif 3186 } 3187 else 3188 align_variable (decl, 0); `decl` get alignment info here but `exp` doesn't. ... 3203 rtl = gen_const_mem (TYPE_MODE (TREE_TYPE (exp)), symbol); 3204 set_mem_attributes (rtl, exp, 1); but here, we use `exp` to set memory attribute for MEM rtl. > I would also strongly recommend turning your testcase into something > we can add to the testsuite. > > If you look in gcc/testsuite/gcc.target/arm you'll see several > examples. I think you just want to compile this down to assembly > code with the optimizer enabled, then verify there is no call to > memcpy in the resulting output. 20030909-1.c would seem to be a > reasonable example of a test that does something similar. Hmmm, it's not target dependent problem, but this problem only can observe by some target since not every target use MEM_ALIGN info for code gen, the most common case is movmem pattern, they use alignment info to decide expand or not. So I am not sure is does it reasonable to make a testcase for target?