From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121488 invoked by alias); 10 Jan 2017 09:23:22 -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 121472 invoked by uid 89); 10 Jan 2017 09:23:21 -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=Monakov, monakov, real_format, our 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; Tue, 10 Jan 2017 09:23:11 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2E1E7ACD3; Tue, 10 Jan 2017 09:23:09 +0000 (UTC) Date: Tue, 10 Jan 2017 09:23:00 -0000 From: Richard Biener To: Alexander Monakov cc: Jakub Jelinek , gcc@gcc.gnu.org, Vladislav Ivanishin Subject: Re: LTO remapping/deduction of machine modes of types/decls In-Reply-To: Message-ID: References: <20170102101931.GB21933@tucnak> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2017-01/txt/msg00080.txt.bz2 On Mon, 9 Jan 2017, Alexander Monakov wrote: > On Wed, 4 Jan 2017, Richard Biener wrote: > > My suggestion at that time isn't likely working in practice due to the > > limitations Jakub outlines below. The situation is a bit unfortunate > > but expect to run into more host(!) dependences in the LTO bytecode. > > Yes, while it would be nice to LTO x86_64->arm and ppc64le->arm > > LTO bytecode it very likely isn't going to work. > > Yes, I think it's not really practical to seek wide portability of LTO bytecode. > After all, platform specifics get into constant expressions (e.g. 'int p = > sizeof (void *);') and are also observable on the preprocessor level (e.g. via > '#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__'). > > However the accelerator platform must be compatible with the host platform in > almost all ABI (storage layout?) features such as type sizes and alignments, > endianness, default signedness of char, bitfield layout, and possibly others > (but yet in the other subthread I was arguing that compromising and making > 'long double' only partially compatible makes sense). Thus, portability issue > is much smaller in scope here. > > I think it's a bit unfortunate that the discussion really focused on the trouble > with floating-point types. I'd really appreciate any insight on the other > questions that were raised, such as whether the decl mode should match that > decl's type mode. In general I think they should match. But without seeing concrete examples of where they do not I can't comment on whether such exceptions make sense. For example if you adjust a DECLs alignment and then re-layout it I'd expect you might get a non-BLKmode mode for an aggregate in some circumstances -- but then decl and type are not 1:1 compatible (due to different alignment), but this case is clearly desired as requiring type copies for the sake of alignment would be wasteful. Generally all "redundancies" we have in decls vs. types expose the possibility of conflicting/non-matching information. > For floating types, I believe in the long run it should be possible to tag tree > type nodes with the floating-point type 'kind' such as IEEE binary, IEEE > decimal, accum/fract/sat, or IBM double-double. The most simplistic solution would be to have a real_format * field in the type (currently there's only a global mode-to-real_format mapping). All types are currently tree_type_non_common (huh), so there's some candidates to put that info on (TYPE_BINFO, though that's used as TYPE_LANG_SLOT_1 - ugh, TYPE_VALUES looks unused though). > For our original goal, I think we'll switch to the other solution I've > outlined in the opening mail, i.e. propagating mode tables at WPA stage > and keeping enough information to know if the section comes from the > host or native compiler. So add a hack ontop of the hack? Ugh. So why exactly doesn't it already work? It looks like decls and types have their modes "fixed" with the per-file mode table at WPA time. So what is missing is to "fix" modes in the per-function sections that are not touched by WPA? Richard. > Thanks. > Alexander > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)