On Wed, 26 Oct 2022, Thomas Schwinge wrote:
> Hi!
>
> Ping. For convenience, I've re-attached
> "options: Clarify 'Init' option property usage for streaming optimization".
> (I've re-verified: "No functional change; no change in generated files.")
OK.
--
Joseph S. Myers
Hi!
Ping. For convenience, I've re-attached
"options: Clarify 'Init' option property usage for streaming optimization".
(I've re-verified: "No functional change; no change in generated files.")
Grüße
Thomas
On 2022-03-31T15:22:59+0200, I wrote:
> Hi!
>
> On 2020-11-18T10:36:35+0100, Jakub
Hi!
On 2020-11-18T10:36:35+0100, Jakub Jelinek via Gcc-patches
wrote:
> 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 stream them more effectively.
>
> This patch implements it and
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
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 stream them more effectively.
This patch implements it and brings
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
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
> 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
> >
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
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
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
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 options and there are 450-ish of them.
Fixed by streaming
14 matches
Mail list logo