From: "relliott@umn.edu" <relliott@umn.edu>
To: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: High memory usage compiling large ‘xxd -i’ output
Date: Sun, 12 Apr 2020 17:01:21 -0500 [thread overview]
Message-ID: <448F1DF6-A77F-43E1-80EA-3C6B99B9F185@umn.edu> (raw)
In-Reply-To: <149f3853f0a495a5f993d38ad60567fa6d10a745.camel@mengyan1223.wang>
Hello,
Thanks for the explanation; I can see the issue now.
Ryan
> On Apr 11, 2020, at 9:16 PM, Xi Ruoyao <xry111@mengyan1223.wang> wrote:
>
> 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
>
prev parent reply other threads:[~2020-04-12 22:01 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
2020-04-12 22:01 ` relliott [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:
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=448F1DF6-A77F-43E1-80EA-3C6B99B9F185@umn.edu \
--to=relliott@umn.edu \
--cc=gcc-help@gcc.gnu.org \
/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).