public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@mengyan1223.wang>
To: "relliott@umn.edu" <relliott@umn.edu>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: High memory usage compiling large ‘xxd -i’ output
Date: Sun, 12 Apr 2020 10:07:52 +0800	[thread overview]
Message-ID: <149f3853f0a495a5f993d38ad60567fa6d10a745.camel@mengyan1223.wang> (raw)
In-Reply-To: <3F1B5DA6-7224-4431-8070-123D18B69B3C@umn.edu>

On 2020-04-11 16:31 -0500, relliott--- via Gcc-help wrote:
> Hello,
> 
> Thanks for your reply.  I guess I don’t understand why this requires so much
> memory all at once.  Is it not possible to write to the object file as the
> initializer is parsed?

A compiler doesn't write to object file.  It only writes to assembly file. 
Modern compilers are designed multi-layer so the parser (frontend) should not
output assembly (it's the job of the backend).  And, doing that so will miss
optimizations.  A simple code:

const int b[] = {0, 1, 2};

int foo(void)
{
  int i, x = 0;
  for (i = 0; i < 3; i++)
    x += b[i];
  return x;
}

The body of "foo" will be optimized to "return 3;" at -O2.  If we wrote the
array content to assembly file and discarded the value in memory, this
optimization will be impossible.

"xxd" a binary file and then compile the result with a compiler is just like
"converting a .jpg to .png then back to .jpg".  A smarter way:

  ld -r -b binary some_big_binary_blob.bin -o some_big_binary_blob.o

There will be symbols _binary_some_big_binary_blob_bin_start,
_binary_some_big_binary_blob_end in some_big_binary_blob.o.  Then it's possible
to access the content of the binary blob with:

  extern const char _binary_some_big_binary_blob_bin_start;
  extern const char _binary_some_big_binary_blob_bin_end;

  int main(void)
  {
    const char *begin = &_binary_some_big_binary_blob_bin_start;
    const char *end = &_binary_some_big_binary_blob_bin_end;
    const char *p;
    for (p = begin; p != end; p++)
      play_with(*p);
  }
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University


  reply	other threads:[~2020-04-12  2:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-11 20:03 relliott
2020-04-11 21:22 ` Jonathan Wakely
2020-04-11 21:31   ` relliott
2020-04-12  2:07     ` Xi Ruoyao [this message]
2020-04-12 22:01       ` relliott

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=149f3853f0a495a5f993d38ad60567fa6d10a745.camel@mengyan1223.wang \
    --to=xry111@mengyan1223.wang \
    --cc=gcc-help@gcc.gnu.org \
    --cc=relliott@umn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).