On Tue, Nov 1, 2016 at 12:14 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Oct 31, 2016 at 05:03:12PM -0400, Jason Merrill wrote:
>> > Ok. Another option would be to call value_format in size_of_die
>> > in this case and put the comment into value_format.
>>
>> That works, too.
>
> Done.
>>
>> >> In general there's a lot of code duplication between the existing ranges
>> >> support and the new rnglist support; even the new vector is a superset of
>> >> the old one. Why duplicate the code rather than modify it?
>> >
>> > The point was to conserve memory for the -gdwarf-{2,3,4} case.
>> > The old table needs just 4 bytes per entry, the new one 16 bytes per entry.
>> > The code duplication because of that is mainly in
>> > add_high_low_attributes - 24 lines duplicated.
>>
>> I was also thinking of the output_rnglists function.
>
> I'm afraid there is nothing that can be shared between output_ranges and
> output_rnglists, except for
> FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)
> {
> int block_num = r->num;
> and
> if (block_num > 0)
> {
> char blabel[MAX_ARTIFICIAL_LABEL_BYTES];
> char elabel[MAX_ARTIFICIAL_LABEL_BYTES];
>
> ASM_GENERATE_INTERNAL_LABEL (blabel, BLOCK_BEGIN_LABEL, block_num);
> ASM_GENERATE_INTERNAL_LABEL (elabel, BLOCK_END_LABEL, block_num);
> so I'd prefer to keep them separate instead of having one function with
> various dwarf_version >= 5 checks (at least 4).
>
>>
>> > At least while -gdwarf-4 is the default that looked to me like acceptable
>> > cost, but if you disagree, I can surely try to just grow the original
>> > table and use it for all versions.
>>
>> Please. I think if we're going in this direction we should just go
>> ahead with it; if the memory consumption is going to be a problem it
>> would be good to find that out so we can address it.
>
> Here it is. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
OK.
Jason
