From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31385 invoked by alias); 20 Jun 2019 12:12:13 -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 31363 invoked by uid 89); 20 Jun 2019 12:12:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=dreams, libgfortran, HTo:U*pinskia X-HELO: cc-smtpout1.netcologne.de Received: from cc-smtpout1.netcologne.de (HELO cc-smtpout1.netcologne.de) (89.1.8.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Jun 2019 12:12:12 +0000 Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 1606E13151; Thu, 20 Jun 2019 14:12:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1561032730; bh=giTvjd8AzLDQyfLovsTDn3pMXjjSleo9jhu3W8z77rU=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To:From; b=gueLKp8CzseuoA1bxQGakkjNWOOG9UEf6aHknVY1uCdqmqp/mERdeJCYuxQZIcWsP qZe3HDHq+oeu0WTpKkxq44bkBLCmDd3D/ieD4ylKCKYhPzEMydJL3BtooLNIvVC5NT llxy3NQ4kO8j5ASXoZ/VSEuqsqee/rfjECc4Xpv0d4z4MoopMm7h7XFOTEY2wN/UJL pgxZr7sMpj1lWajoPwEchKhGyuqhKDK1T/s05uka9hT3o/eyDBzBa0q6EHgFgYdiF7 G2hSIFXabs8ecLKL/vm7oBnpkpIcZDVJo+ONkOxvQsNnKxvlQCNNqX+sAdLaLrf8lZ YR2tYjg4XAslw== Received: from localhost (localhost [127.0.0.1]) by cc-smtpin1.netcologne.de (Postfix) with ESMTP id 11E9A11D73; Thu, 20 Jun 2019 14:12:10 +0200 (CEST) Received: from [2001:4dd7:7e7b:0:7285:c2ff:fe6c:992d] (helo=cc-smtpin1.netcologne.de) by localhost with ESMTP (eXpurgate 4.6.0) (envelope-from ) id 5d0b781a-1e16-7f0000012729-7f0000019fa6-1 for ; Thu, 20 Jun 2019 14:12:10 +0200 Received: from [IPv6:2001:4dd7:7e7b:0:7285:c2ff:fe6c:992d] (2001-4dd7-7e7b-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:7e7b:0:7285:c2ff:fe6c:992d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cc-smtpin1.netcologne.de (Postfix) with ESMTPSA; Thu, 20 Jun 2019 14:12:01 +0200 (CEST) Subject: Re: [RFC] zstd as a compression algorithm for LTO To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Andrew Pinski , Jan Hubicka Cc: Richard Biener , Jeff Law , GCC Development , GCC Patches , fortran@gcc.gnu.org References: <89e98dc0-e766-ffef-da0f-263c3b284e96@suse.cz> <1BBDAEDD-9432-4B12-BA20-63A6E047FDB6@gmail.com> <20190619192954.edwdfxns3gx2gt5m@kam.mff.cuni.cz> <122f53d2-5ae0-b801-81ab-36ce69f9efda@netcologne.de> <9417a329-c71c-4682-872c-60ff3524c47e@suse.cz> From: Thomas Koenig Message-ID: Date: Thu, 20 Jun 2019 12:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <9417a329-c71c-4682-872c-60ff3524c47e@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00213.txt.bz2 Hi Martin, > LTO bytecode is not supposed to be a distributable format. One of my dreams is to make libgfortran LTO-clean. There is a lot of performance to be gained both in I/O (where a huge number of special cases could be shortcut by LTO, because hardly any program uses them all) and in array intrinsics, where seeing through the array descriptors can also lead to large benefits. This is PR 77278. Once this is achieved, it would make sense to distribute libgfortran.a as a library of fat object files. Regards Thomas