public inbox for
 help / color / mirror / Atom feed
From: Jakub Jelinek <>
To: Mark Wielaard <>
Subject: Re: [PATCH 4/4] Handle DW_FORM_implicit_const [experiment].
Date: Thu, 24 Sep 2020 21:57:39 +0200	[thread overview]
Message-ID: <20200924195739.GR2176@tucnak> (raw)
In-Reply-To: <>

On Thu, Sep 24, 2020 at 06:25:57PM +0200, Mark Wielaard wrote:
> --- a/dwz.c
> +++ b/dwz.c
> @@ -848,6 +848,8 @@ struct abbrev_attr
>    unsigned int attr;
>    /* DW_FORM_* form code.  */
>    unsigned int form;
> +  /* Only for DW_FORM_implicit_const.  */
> +  int64_t value;
>  };

Indeed, this is the most expensive choice memory-wise, but I guess it might
be interesting to take some very large dwz run (e.g. the webkits) and
measure how many abbrev_attr structs we have actually allocated at peak time
and whether it just isn't acceptable.  It is true we'd waste all that memory
e.g. when processing DWARF4 and never actually use it in that case.
On the other side, it is the cleanest and fastest approach.

Another possibility is to add int64_t * field to struct abbrev_tag and
if the abbreviation contains at least one DW_FORM_implicit_const, then
allocate tail payload of int64_ts (either nattr of them, or perhaps optimize
and allocate only index of highest DW_FORM_implicit_const + 1 ones,
or optimize even more and allocate index of highest DW_FORM_implicit_const
- index of lowest DW_FORM_implicit_const + 1 times int64_t and point the
pointer earlier such that t1->value[i] would be the the value for each
DW_FORM_implicit_const).  Or even optimize memory even more and just
allocate as many int64_ts as there are DW_FORM_implicit_const forms.
Except that then all the loops that iterate from 0 to nattr looking through
the attributes would need to track how many DW_FORM_implicit_const were seen
(or there would need to be another loop to count that afterwards).


      reply	other threads:[~2020-09-24 19:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 16:25 Read and write DWARF5 units and forms Mark Wielaard
2020-09-24 16:25 ` [PATCH 1/4] Calculate size and write correct DWARF5 header Mark Wielaard
2020-09-24 19:39   ` Jakub Jelinek
2020-09-25 16:35     ` Mark Wielaard
2020-09-25 16:39       ` Jakub Jelinek
2020-09-24 16:25 ` [PATCH 2/4] Handle DW_FORM_data16 Mark Wielaard
2020-09-24 19:43   ` Jakub Jelinek
2020-09-24 21:53     ` Jakub Jelinek
2020-09-25 16:42     ` Mark Wielaard
2020-09-24 16:25 ` [PATCH 3/4] Handle DW_FORM_line_strp by not moving DIE Mark Wielaard
2020-09-24 19:45   ` Jakub Jelinek
2020-09-24 16:25 ` [PATCH 4/4] Handle DW_FORM_implicit_const [experiment] Mark Wielaard
2020-09-24 19:57   ` Jakub Jelinek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200924195739.GR2176@tucnak \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).