From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11730 invoked by alias); 14 Nov 2014 18:25:11 -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 11717 invoked by uid 89); 14 Nov 2014 18:25:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Nov 2014 18:25:09 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XpLYQ-0004ce-4n from Bernd_Schmidt@mentor.com ; Fri, 14 Nov 2014 10:25:06 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Fri, 14 Nov 2014 18:25:04 +0000 Message-ID: <5466483C.1040107@codesourcery.com> Date: Fri, 14 Nov 2014 18:42:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Jeff Law , GCC Patches CC: Ilya Verbin , Uros Bizjak Subject: Re: nvptx offloading patches [3/n], i386 bits RFD References: <5454CAB9.3040907@codesourcery.com> <5458016A.4080109@redhat.com> <5458C7F8.8080702@codesourcery.com> <54594A29.507@redhat.com> <54596D22.8010406@codesourcery.com> In-Reply-To: <54596D22.8010406@codesourcery.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg01864.txt.bz2 On 11/05/2014 01:19 AM, Bernd Schmidt wrote: > On 11/04/2014 10:50 PM, Jeff Law wrote: >> No, I don't think it's terminology. It's really that in effect we have >> two targets. One is a normal CPU, the other is a GPU. >> >> ie, there's nothing that says we won't have a GPU that's being driven by >> an ARM or PPC. What I want to avoid is GPU-isms getting sprinkled into >> the x86 (or any other) backend. >> >> The problem is we don't have any infrastructure in place for this kind >> of situation. So we start off with a few hacks and hopefully we're able >> to see some commonality and start to see how to handle the >> multi-architecture target issues a bit better. > > FWIW the three non-ptx patches I sent plus the -foffload-abi stuff are > the only ones necessary to make offloading through the LTO path work > (this was against the gomp-4_0-branch with earlier versions of the > offload patches Ilya's been posting; I haven't had a chance to test > everything together in trunk yet). That doesn't seem like a large amount > of changes. > > For other targets I don't expect the situation to be too different. ARM > has a similar float mode issue for HFmode, and things like > m{big,little}-endian may have to be handled. I expect these can be > handled with -foffload-abi machinery. > > So, looking ahead - I'm imagining extra switches along the lines of > -foffload-abi-hflt={arm,ieee,...} > -foffload-abi-ldbl={64,x86,128} > -foffload-abi-endian={big,little} > > On some targets it might make sense to disallow offloading if certain > switches are used. Uros seems to agree that on x86 the -mlong-double-128 > switch isn't very interesting. I'm thinking about how to deal with such > a situation - maybe an offload_abi_valid hook that gets called whenever > we find that we want to stream out offloaded functions. That would then > sorry out (or maybe just warn) if the hook returns false. > > I can do either or both, whatever the consensus turns out to be. The discussion on these patches kind of stalled, so a gentle ping - it would be nice to integrate these now that Ilya's offload patches are in. Bernd