> On Fri, May 27, 2011 at 10:54 AM, Jan Hubicka wrote:
> > Hi,
> > here is updated patch incorporating the feedback. I now use variant of
> > uleb format,
> > just do 4 bit chunks instead of 8bit. It works better in my tests and is
> > also used
> > by LLVM so it must be cool ;)
> >
> > I also
On Fri, May 27, 2011 at 10:54 AM, Jan Hubicka wrote:
> Hi,
> here is updated patch incorporating the feedback. I now use variant of uleb
> format,
> just do 4 bit chunks instead of 8bit. It works better in my tests and is also
> used
> by LLVM so it must be cool ;)
>
> I also fixed off by one e
Hi,
here is updated patch incorporating the feedback. I now use variant of uleb
format,
just do 4 bit chunks instead of 8bit. It works better in my tests and is also
used
by LLVM so it must be cool ;)
I also fixed off by one error in filename streaming. While debugging this I
noticed that bitpa
Hi,
On Thu, 26 May 2011, Richard Guenther wrote:
> > Hmm, I plan to optimize string streaming (since we always stream one
> > uleb to set it is non-NULL that can be easilly handled by assigining
> > NULL string index 0). How precisely you however suggest to bitpack
> > line/column and string
2011/5/26 Jan Hubicka :
>> 2011/5/26 Jan Hubicka :
>> >> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote:
>> >> >>
>> >> >> This looks all very hackish with no immediate benefit mostly because
>> >> >> of the use of lto_output_string. I think what you should do instead
>> >> >> is split up lt
> 2011/5/26 Jan Hubicka :
> >> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote:
> >> >>
> >> >> This looks all very hackish with no immediate benefit mostly because
> >> >> of the use of lto_output_string. I think what you should do instead
> >> >> is split up lto_output_string_with_length in
2011/5/26 Jan Hubicka :
>> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote:
>> >>
>> >> This looks all very hackish with no immediate benefit mostly because
>> >> of the use of lto_output_string. I think what you should do instead
>> >> is split up lto_output_string_with_length into the piece
> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote:
> >>
> >> This looks all very hackish with no immediate benefit mostly because
> >> of the use of lto_output_string. I think what you should do instead
> >> is split up lto_output_string_with_length into the piece that streams
> >> the string
On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote:
>>
>> This looks all very hackish with no immediate benefit mostly because
>> of the use of lto_output_string. I think what you should do instead
>> is split up lto_output_string_with_length into the piece that streams
>> the string itself to t
> >
> > This looks all very hackish with no immediate benefit mostly because
> > of the use of lto_output_string. I think what you should do instead
> > is split up lto_output_string_with_length into the piece that streams
> > the string itself to the string-stream and returns an index into it
>
>
> This looks all very hackish with no immediate benefit mostly because
> of the use of lto_output_string. I think what you should do instead
> is split up lto_output_string_with_length into the piece that streams
> the string itself to the string-stream and returns an index into it
> and the pi
On Thu, May 26, 2011 at 11:34 AM, Jan Hubicka wrote:
> Hi,
> we spend a lot of effort (and disk space) into streaming file/line/column and
> sys_p fields of locations. Since often the trees come from same statement, it
> is common for those to not change. We even already have current location inf
Hi,
we spend a lot of effort (and disk space) into streaming file/line/column and
sys_p fields of locations. Since often the trees come from same statement, it
is common for those to not change. We even already have current location info
in output_block and data_in, but don't use it.
This patch u
13 matches
Mail list logo
