From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107407 invoked by alias); 30 Apr 2015 10:00:06 -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 107392 invoked by uid 89); 30 Apr 2015 10:00:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Apr 2015 10:00:04 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4903A29; Thu, 30 Apr 2015 02:59:36 -0700 (PDT) Received: from collaborate-mta1.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTP id 68E6D3F21A; Thu, 30 Apr 2015 03:00:02 -0700 (PDT) Received: from [10.2.206.27] (e105545-lin.cambridge.arm.com [10.2.206.27]) by collaborate-mta1.arm.com (Postfix) with ESMTPS id B09C613F884; Thu, 30 Apr 2015 05:00:01 -0500 (CDT) Message-ID: <5541FD20.2000700@arm.com> Date: Thu, 30 Apr 2015 10:26:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christian Bruel CC: Richard Earnshaw , "gcc-patches@gcc.gnu.org" Subject: Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6] References: <54D8A94E.3010603@st.com> <5534BA3F.8060602@st.com> <5541E962.4090202@st.com> In-Reply-To: <5541E962.4090202@st.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg01992.txt.bz2 >>> Christian >> >> >> A general note, please reply to each of the patches with a rebased >> patch as a separate email. Further more all your patches appear to >> have dos line endings so they don't seem to apply cleanly. Please >> don't have spurious headers in your patch submission - it then makes >> it hard to , please create it in a way that it is easily applied by >> someone trying it out. It looks like p4 needs a respin as I got a >> reject trying to apply the documentation patch to my tree while trying >> to apply it. >> > > OK, thanks for the suggestions and sorry for the p4 reject. The sources > are moving fast and I have hard times catching up with re-bases. I understand. > >> I tried the following decoration on foo in gcc.target/arm/attr_arm.c >> >> >> int __attribute__((target("arm, fpu=vfpv4"))) >> foo(int a) >> { >> return a ? 1 : 5; >> } >> >> >> And the compiler accepts it just fine. > > Indeed, it's a mistake for now. attributes other the arm/thumb ones > shall be rejected (eventually with a "not yet implemented" warning for > the fpu, error for the others.) until we extend it. Yep - funnily enough if you remove "arm" and just use "fpu=vfpv4", I think you get an error. > >> >> Given that with LTO we are now using target attributes to decide >> inlining - I'm not convinced that the inline asm case goes away. In >> fact it only makes things worse so I'm almost convinced to forbid >> inlining from "arm" to "thumb" or vice-versa, which is a reversal of >> my earlier position. I hadn't twigged that LTO would reuse this >> infrastructure and it's probably simpler to prevent inlining in those >> cases. > > I can resurrect the inline check chunk. FYI, with a few small examples > arm/thumb attribute is correctly handled by LTO Yes it would work with normal C code as it does normally - I'm worried about functions with inline asm. We've just increased the inlining scope with lto and that would mean things are a bit more painful ? > >> >> Thoughts ? >> >> So in essence I'm still playing with this and would like to iterate >> towards a quick solution. >> > > thanks, that would be good if we could land the arm/thumb attribute and > start the fpu extensions separately. (I'm currently playing with > fpu=neon but it will take time to have something solid). Absolutely - I'd rather spend the time first in polishing this up. Extending it for other options can be something you look at separately. BTW I was pointed at a PR for this yesterday by a colleague - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 So, lets use that as the PR for this work. regards Ramana > > Christian > >> Ramana >> >