On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> Reposting with self-contained description per Joseph's request:
>
> Honza mentioned that especially for the new param machinery, most of
> streamed values are probably going to be the default values. Perhaps
> somehow we could
On Mon, Sep 14, 2020 at 11:47:56AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 14, 2020 at 11:02:26AM +0200, Jan Hubicka wrote:
> > Especially for the new param machinery, most of streamed values are
> > probably going to be the default values. Perhaps somehow we could
> > stream the
On Mon, Sep 14, 2020 at 11:02:26AM +0200, Jan Hubicka wrote:
> Especially for the new param machinery, most of streamed values are
> probably going to be the default values. Perhaps somehow we could
> stream them more effectively.
Ah, that seems like a good idea, that brings further savings, the
On Mon, 14 Sep 2020, Jakub Jelinek wrote:
> On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> > But does it make any noticable difference in the end? Using
>
> Yes.
>
> > bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> > rather than full bytes. Using hardc
> On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> > But does it make any noticable difference in the end? Using
>
> Yes.
>
> > bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> > rather than full bytes. Using hardcoded 8/16/32/64 makes it still
> > dependen
On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> But does it make any noticable difference in the end? Using
Yes.
> bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> rather than full bytes. Using hardcoded 8/16/32/64 makes it still
> dependent on what 'int'
On Mon, 14 Sep 2020, Jakub Jelinek wrote:
> 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 l
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 boole
On Sun, 13 Sep 2020, Jakub Jelinek wrote:
> Hi!
>
> 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 opti
