From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 514 invoked by alias); 4 Jan 2017 10:14:44 -0000 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 Received: (qmail 477 invoked by uid 89); 4 Jan 2017 10:14:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jan 2017 10:14:37 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 070F7AAB7; Wed, 4 Jan 2017 10:14:35 +0000 (UTC) Date: Wed, 04 Jan 2017 10:14:00 -0000 From: Richard Biener To: Jakub Jelinek cc: Alexander Monakov , gcc@gcc.gnu.org, Vladislav Ivanishin Subject: Re: LTO remapping/deduction of machine modes of types/decls In-Reply-To: <20170102190255.GG21933@tucnak> Message-ID: References: <20170102101931.GB21933@tucnak> <20170102155403.GE21933@tucnak> <20170102190255.GG21933@tucnak> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2017-01/txt/msg00018.txt.bz2 On Mon, 2 Jan 2017, Jakub Jelinek wrote: > On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote: > > On Mon, 2 Jan 2017, Jakub Jelinek wrote: > > > If the host has long double the same as double, sure, PTX can use its native > > > DFmode even for long double. But otherwise, the storage must be > > > transferable between accelerator and host. > > > > Hm, sorry, the 'must' is not obvious to me: is it known that the OpenMP ARB > > would find only this implementation behavior acceptable? > > long double is not non-mappable type in the spec, so it is supposed to work. > The implementation may choose not to offload whenever it sees long > double/__float128/_Float128/_Float128x etc. > > > Apart from floating-point types, are there other situations where modes carry > > information not deducible from the rest of the tree node? > > Dunno about fixed types, partial ints etc., but it is mostly floating point > types, sure. Mostly floats I guess. But just to say it would be very nice to have enough information in the trees so layout_type can re-construct the mode. It already does for 99% of the types... (just grep for SET_TYPE_MODE). Richard.