From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2054 invoked by alias); 9 Jan 2017 18:56:06 -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 2042 invoked by uid 89); 9 Jan 2017 18:56:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=compromising, outlined, remapping, accelerator X-HELO: smtp.ispras.ru Received: from bran.ispras.ru (HELO smtp.ispras.ru) (83.149.199.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jan 2017 18:56:03 +0000 Received: from monopod.intra.ispras.ru (monopod.intra.ispras.ru [10.10.3.121]) by smtp.ispras.ru (Postfix) with ESMTP id BEB2960912; Mon, 9 Jan 2017 21:56:00 +0300 (MSK) Date: Mon, 09 Jan 2017 18:56:00 -0000 From: Alexander Monakov To: Richard Biener 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.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2017-01/txt/msg00072.txt.bz2 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. 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. 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. Thanks. Alexander