From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 6A84D38460A3 for ; Mon, 14 Sep 2020 07:00:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6A84D38460A3 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-468-E8hNEZ82MdiOfoMoaCLtSA-1; Mon, 14 Sep 2020 03:00:56 -0400 X-MC-Unique: E8hNEZ82MdiOfoMoaCLtSA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0980B18B9ECA; Mon, 14 Sep 2020 07:00:55 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-252.ams2.redhat.com [10.36.113.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 43E9E21E7F; Mon, 14 Sep 2020 07:00:54 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 08E70oxp024553; Mon, 14 Sep 2020 09:00:50 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 08E70m0v024551; Mon, 14 Sep 2020 09:00:48 +0200 Date: Mon, 14 Sep 2020 09:00:48 +0200 From: Jakub Jelinek To: Richard Biener Cc: "Joseph S. Myers" , Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] options, lto: Optimize streaming of optimization nodes Message-ID: <20200914070048.GT21814@tucnak> Reply-To: Jakub Jelinek References: <20200913083327.GG21814@tucnak> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 07:01:03 -0000 On Mon, Sep 14, 2020 at 08:39:22AM +0200, Richard Biener wrote: > > When working on the previous patch, I've noticed that all cl_optimization > > fields appart from strings are streamed with bp_pack_value (..., 64); so we > > waste quite a lot of space, given that many of the options are just booleans > > or char options and there are 450-ish of them. > > > > Fixed by streaming the number of bits the corresponding fields have. > > While for char fields we have also range information, except for 3 > > it is either -128, 127 or 0, 255, so it didn't seem worth it to bother > > with using range-ish packing. > > > > Bootstrapped/regtested on x86_64-linux, i686-linux, armv7hl-linux-gnueabi, > > aarch64-linux, powerpc64le-linux and lto bootstrapped on x86_64-linux, ok > > for trunk? > > Hmm, in principle the LTO bytecode format should be not dependent > on the host, while it probably doesn't work right now to move > 32bit host to 64bit host targeting the same target bytecode files > the following makes explicit use of HOST_* and that might have been > the reason we're using 64bit encodings for everything. Note > using 64bits isn't too bad in practice since we uleb encode the > bitpack words and outputing 64bits basically ensures we're outputting > a stream of uleb encoded uint64_t. So would using hardcoded 8, 16, 32 and 64 be better? I mean, we certainly assume the -128, 127 or 0, 255 ranges e.g. for chars. There are ~ 4 strings, 226 chars, 222 ints/enums in my options-save.c bp_pack_* calls and 39 64-bit (which includes the target stuff) on x86_64-linux. Another option is using the variable length bp_pack_var_len_unsigned/bp_pack_var_len_int for everything, I guess most of the char options are 0/1/2, most of the params are smallish too (though there are some 100s, 1000s and 10000s and even higher, but most of them are small). Either the awk script would need to figure out which are guaranteed to be unsigned and use *_unsigned for them and use *_int for rest, or we'd need to use *_int everywhere. Jakub