From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17754 invoked by alias); 29 Nov 2007 08:56:00 -0000 Received: (qmail 17745 invoked by uid 22791); 29 Nov 2007 08:55:59 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 Nov 2007 08:55:49 +0000 Received: by nf-out-0910.google.com with SMTP id h3so2128272nfh for ; Thu, 29 Nov 2007 00:55:47 -0800 (PST) Received: by 10.78.203.15 with SMTP id a15mr215505hug.1196326546690; Thu, 29 Nov 2007 00:55:46 -0800 (PST) Received: by 10.78.160.17 with HTTP; Thu, 29 Nov 2007 00:55:46 -0800 (PST) Message-ID: <67ea2eb0711290055m179ee491x8293bf1963dce32f@mail.gmail.com> Date: Thu, 29 Nov 2007 14:53:00 -0000 From: "Ramana Radhakrishnan" To: "Michael Meissner" , gcc@gcc.gnu.org, christophe.harle@amd.com Subject: Re: Function specific optimizations call for discussion In-Reply-To: <20071128205737.GA28277@mmeissner-gold.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071128205737.GA28277@mmeissner-gold.amd.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00825.txt.bz2 Hi, Hit the send button a bit too soon on my earlier mail . > In the x86 world this would mean saying that an individual function can use > SSE5 instructions or SSE4.1 instructions. This would simplify things for > people who need to write high performance libraries that run on different > architectures, and need to be optimal on each platform. Ultimately, the goal > is to allow hotspot functions to be compiled several times with different > target specific optimizations. I would welcome any thoughts or suggestions > about this proposal. I noticed this from your proposal. Stage1: Teach the inliner about target specific functions We will teach the inliner not to inline functions compiled with target specific optimizations inside of a general function. However, if a function that has target specific optimizations it should be able to inline normal functions, or functions compiled with the same set of target specific optimizations. I estimate that this should take 2 weeks of time. This is already handled in the inliner and could be handled by defining the target hook TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P .We use it in the private port that we maintain to disable inlining of certain attributed functions like interrupt handlers. The way we do it already is to look at DECL_ATTRIBUTES of the tree to figure this out. You would have to munge in the attributes into the DECL_ATTRIBUTES and the check later when you do the same but I guess you know that already. cheers Ramana On Nov 29, 2007 2:27 AM, Michael Meissner wrote: > One of the things that I've been interested in is adding support to GCC to > compile individual functions with specific target options. I first presented a > draft at the Google mini-summit, and then another draft at the GCC developer > summit last July. > > In the x86 world this would mean saying that an individual function can use > SSE5 instructions or SSE4.1 instructions. This would simplify things for > people who need to write high performance libraries that run on different > architectures, and need to be optimal on each platform. Ultimately, the goal > is to allow hotspot functions to be compiled several times with different > target specific optimizations. I would welcome any thoughts or suggestions > about this proposal. > > The proposal is at: > http://gcc.gnu.org/wiki/FunctionSpecificOpt > > Part of the infrastructure work for doing this is already addressed in function > adaption project and we will work together with that team: > http://gcc.gnu.org/wiki/functionAdaptation > > One of the things that I have considered and not added to the current proposal > is to change most of the -f, -O, -W options for a function. This would be > relatively simple to add once the infrastructure is in place, but it can really > complicate things, since various optimizations depend on other optimizations > having been done. Similarly, the -mtune= and -march= options can overly > complicate matters. > > In addition, attribute(cold) and attribute(hot) will set the optimization level > to -Os and -O3. > > I will be away on vacation from December 3-8th, and not reading mail during > that time. > > -- > Michael Meissner, AMD > 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA > michael.meissner@amd.com > > > -- Ramana Radhakrishnan