From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16511 invoked by alias); 4 Feb 2015 11:38:27 -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 16494 invoked by uid 89); 4 Feb 2015 11:38:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_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; Wed, 04 Feb 2015 11:38:26 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14BcNBI011564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Feb 2015 06:38:23 -0500 Received: from tucnak.zalov.cz (ovpn-116-42.ams2.redhat.com [10.36.116.42]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t14BcLEH013242 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Feb 2015 06:38:22 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t14BcJlY020880; Wed, 4 Feb 2015 12:38:20 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t14BcHk5020879; Wed, 4 Feb 2015 12:38:17 +0100 Date: Wed, 04 Feb 2015 11:38:00 -0000 From: Jakub Jelinek To: Bernd Schmidt Cc: GCC Patches , Ilya Verbin Subject: Re: nvptx offloading patches [3/n], RFD Message-ID: <20150204113817.GO1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5454CAB9.3040907@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5454CAB9.3040907@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00226.txt.bz2 On Sat, Nov 01, 2014 at 12:57:45PM +0100, Bernd Schmidt wrote: > This is not against current trunk; it applies to gomp-4_0-branch where it is > one of the necessary parts to make offloading x86->nvptx work. The issue is > that the LTO file format depends on the machine_modes enum, it needs to > match between host and offload target. The easiest way to do this is to just > use the host-modes.def when compiling an offload compiler. > > Ports that want to be hosts for offloading may need to modify their > modes.def. The patch below contains changes to i386-modes.def which modifies > XFmode depending on a target switch. I'm not actually entirely sure what to > do about this. Do we want to make this flag an error when offloading is > enabled? Or maybe add float format support to the -foffload-abi option? > > Thoughts? Ok for the first part of the patch once the other offloading > patches have gone in (bootstrapped and tested on x86_64-linux)? I don't like this at all. IMHO instead we should stream in the offloading LTO sections some kind of mode description table (perhaps limited to the modes actually ever streamed), and when reading back the offloading LTO sections, let the offloading compiler remap the modes to its own modes where there is a mapping in between the two, choose some other mapping (e.g. map various vector modes the host has but offloading target does not to say BLKmode), or give up otherwise with offloading (say if you attempt to stream floating point modes the offloading target doesn't support etc.). So perhaps stream for each used mode the mode value, corresponding mode class, size, precision, inner mode, nunits, and for floating point modes supposedly somehow encode the real_format (perhaps just add a name <-> struct real_format mapping for the real.c modes, and map anything else to "unknown"). Jakub