public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	Jan Hubicka <jh@suse.cz>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] options, lto: Optimize streaming of optimization nodes
Date: Mon, 14 Sep 2020 09:00:48 +0200	[thread overview]
Message-ID: <20200914070048.GT21814@tucnak> (raw)
In-Reply-To: <nycvar.YFH.7.76.2009140833580.9963@zhemvz.fhfr.qr>

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


  reply	other threads:[~2020-09-14  7:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-13  8:33 Jakub Jelinek
2020-09-14  6:39 ` Richard Biener
2020-09-14  7:00   ` Jakub Jelinek [this message]
2020-09-14  7:31     ` Richard Biener
2020-09-14  8:48       ` Jakub Jelinek
2020-09-14  9:02         ` Jan Hubicka
2020-09-14  9:47           ` Jakub Jelinek
2020-10-05  9:21             ` Patch ping (Re: [PATCH] options, lto: Optimize streaming of optimization nodes) Jakub Jelinek
2020-11-18  9:36               ` [PATCH] options, lto: Optimize streaming of optimization nodes Jakub Jelinek
2020-11-18 19:06                 ` Joseph Myers
2022-03-31 13:22                 ` options: Clarify 'Init' option property usage for streaming optimization (was: [PATCH] options, lto: Optimize streaming of optimization nodes) Thomas Schwinge
2022-10-26 13:46                   ` [PING] " Thomas Schwinge
2022-10-26 18:21                     ` Joseph Myers
2020-09-14  9:23         ` [PATCH] options, lto: Optimize streaming of optimization nodes Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200914070048.GT21814@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jh@suse.cz \
    --cc=joseph@codesourcery.com \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).