From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17233 invoked by alias); 27 Jun 2014 22:35:05 -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 17142 invoked by uid 89); 27 Jun 2014 22:35:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 27 Jun 2014 22:35:02 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5RMYtwg019081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 27 Jun 2014 18:34:56 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-44.phx2.redhat.com [10.3.113.44]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5RMYspZ023203; Fri, 27 Jun 2014 18:34:55 -0400 Message-ID: <53ADF18E.9090404@redhat.com> Date: Fri, 27 Jun 2014 22:35:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kito Cheng CC: gcc-patches@gcc.gnu.org, Jan Hubicka , Richard Sandiford , Eric Botcazou , Ramana Radhakrishnan Subject: Re: [PATCH] Pass correct memory attributes for build constant References: <53AB38AB.7040901@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg02276.txt.bz2 On 06/25/14 21:38, Kito Cheng wrote: > For example in arm-elf-eabi, movmem need word align, otherwise it will > expand a libcall: > > And gcc configure with "--target=arm-elf-eabi --disable-nls > --disable-shared --enable-languages=c,c++ --enable-threads=single > --enable-lto --with-newlib" > > 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 alignment like you want? I can see how that *section* gets its alignment, but I don't offhand see what in the ARM backend ensures that a CONSTRUCTOR tree has larger than normal known alignment. 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). 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. Jeff