Re: Faster streaming of enums

2011-05-26 Thread Tom Tromey
> "Jan" == Jan Hubicka writes: Some typos... Jan> + /* Pack VAL into BP, be more effetive when VAL is small. Jan> +Implementation is sily, we may want to do better later. */ "effective" and "silly". Jan> + /* Pack VAL into BP, be more effetive when VAL is small. Jan> +Implementati

Re: Faster streaming of enums

2011-05-26 Thread Jan Hubicka
Hi, this is updated patch. For whatever reason we now end up with longer .o file for tramp3d than with my prevoius attempt (by 9KB). We need at average 15 bytes for location, well, the encoding of small ints might be better with uleb style, perhaps with smaller chunk (like 4 bits per chunk as oppo

Re: Faster streaming of enums

2011-05-25 Thread Richard Guenther
On Wed, 25 May 2011, Jan Hubicka wrote: > > > *** lto_output_tree (struct output_block *ob > > > *** 1401,1407 > > >         will instantiate two different nodes for the same object.  */ > > >        output_record_start (ob, LTO_tree_pickle_reference); > > >        output_uleb128

Re: Faster streaming of enums

2011-05-25 Thread Jan Hubicka
> > *** lto_output_tree (struct output_block *ob > > *** 1401,1407 > >         will instantiate two different nodes for the same object.  */ > >        output_record_start (ob, LTO_tree_pickle_reference); > >        output_uleb128 (ob, ix); > > !       output_uleb128 (ob, lto_tree_

Re: Faster streaming of enums

2011-05-25 Thread Richard Guenther
On Wed, May 25, 2011 at 11:45 AM, Jan Hubicka wrote: > Hi, > after fixing 1 byte i/o function call and most of hash table overhead, > functions to handle ulebs and slebs shows top in profile.  We use them in > many cases where we know value range of the operand will fit in 1 byte. In > particular