From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13350 invoked by alias); 5 Nov 2014 00:23:15 -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 13340 invoked by uid 89); 5 Nov 2014 00:23:14 -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; Wed, 05 Nov 2014 00:23:11 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XloNP-0004o2-9z from Bernd_Schmidt@mentor.com ; Tue, 04 Nov 2014 16:23:07 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.181.6; Wed, 5 Nov 2014 00:23:06 +0000 Message-ID: <54596D22.8010406@codesourcery.com> Date: Wed, 05 Nov 2014 00:23: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> In-Reply-To: <54594A29.507@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00251.txt.bz2 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. Bernd