public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sherpya at netfarm dot it" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/42776] LTO doesn't work on non-ELF platforms.
Date: Mon, 12 Apr 2010 16:56:00 -0000 [thread overview]
Message-ID: <20100412165552.13506.qmail@sourceware.org> (raw)
In-Reply-To: <bug-42776-14373@http.gcc.gnu.org/bugzilla/>
------- Comment #39 from sherpya at netfarm dot it 2010-04-12 16:55 -------
(In reply to comment #35)
> So if I understand correctly, the "state of things" at the moment is this:
>
> Without LTO:
> > Time: 419.938 sec (6 m 59 s)
>
> with LTO incl linker flags:
> > Time: 443.047 sec (7 m 23 s)
>
> In other words, "with LTO" is ~6% slower than without.
>
> You say that "results aren't exactly as expected" but I think there is really
> not much you can expect.
>
> First of all, as it is, in GCC 4.5 LTO/WHOPR does not do a whole lot at all. It
> is really only inlining across translation unit boundaries.
>
> Second, LTO doesn't miraculously increase the number of optimization
> opportunities, and very often it makes things worse on register-starved
> architectures like i686 (see
> http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf for folklore vs. fact in
> re. interprocedural optimization).
>
> Third, for C/C++ programs the source code is usually already organized in such
> a way to avoid requiring a whole-program view of the program for the compiler
> to optimize well. Think .h header files, static inline functions, by-value call
> conventions, etc. And although I don't know clamav very well, I suspect it's
> completely I/O bound so optimizing away memory latencies etc. (which is really
> what LTO is mostly about) wouldn't help for clamav anyway.
>
> That doesn't mean that optimizing LTO should slow down your program. It would
> be interesting to see if it's somehow possible to identify the part of the
> program that got slower.
>
6% slower for a new work in progress feature is ok for me, while 60% not :)
clamav has a lot of io but also a lot of cpu so it can used for such tests
but definitively this patch is usable and could provide more feedbacks to lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
next prev parent reply other threads:[~2010-04-12 16:56 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-17 15:59 [Bug lto/42776] New: " davek at gcc dot gnu dot org
2010-01-17 16:09 ` [Bug lto/42776] " davek at gcc dot gnu dot org
2010-01-17 16:13 ` davek at gcc dot gnu dot org
2010-01-18 11:02 ` d dot g dot gorbachev at gmail dot com
2010-01-18 11:05 ` davek at gcc dot gnu dot org
2010-01-18 11:51 ` d dot g dot gorbachev at gmail dot com
2010-01-18 12:55 ` davek at gcc dot gnu dot org
2010-01-18 16:18 ` steven at gcc dot gnu dot org
2010-01-18 16:36 ` davek at gcc dot gnu dot org
2010-01-21 7:10 ` davek at gcc dot gnu dot org
2010-01-21 7:14 ` davek at gcc dot gnu dot org
2010-01-21 19:47 ` davek at gcc dot gnu dot org
2010-01-22 1:18 ` d dot g dot gorbachev at gmail dot com
2010-01-22 10:46 ` davek at gcc dot gnu dot org
2010-02-03 10:15 ` d dot g dot gorbachev at gmail dot com
2010-02-03 12:02 ` davek at gcc dot gnu dot org
2010-02-03 14:46 ` davek at gcc dot gnu dot org
2010-02-03 14:48 ` davek at gcc dot gnu dot org
2010-02-03 16:10 ` davek at gcc dot gnu dot org
2010-02-04 17:12 ` davek at gcc dot gnu dot org
2010-02-12 20:57 ` steven at gcc dot gnu dot org
2010-02-13 1:06 ` davek at gcc dot gnu dot org
2010-02-13 10:24 ` rguenth at gcc dot gnu dot org
2010-04-09 3:55 ` sherpya at netfarm dot it
2010-04-09 3:56 ` sherpya at netfarm dot it
2010-04-09 3:57 ` davek at gcc dot gnu dot org
2010-04-09 4:02 ` sherpya at netfarm dot it
2010-04-09 4:04 ` sherpya at netfarm dot it
2010-04-09 4:11 ` davek at gcc dot gnu dot org
2010-04-09 18:30 ` sherpya at netfarm dot it
2010-04-09 19:48 ` sherpya at netfarm dot it
2010-04-10 16:20 ` davek at gcc dot gnu dot org
2010-04-11 17:38 ` sherpya at netfarm dot it
2010-04-11 22:59 ` steven at gcc dot gnu dot org
2010-04-11 23:58 ` sherpya at netfarm dot it
2010-04-12 10:41 ` steven at gcc dot gnu dot org
2010-04-12 13:30 ` davek at gcc dot gnu dot org
2010-04-12 15:58 ` steven at gcc dot gnu dot org
2010-04-12 16:11 ` ro at gcc dot gnu dot org
2010-04-12 16:56 ` sherpya at netfarm dot it [this message]
2010-04-13 5:59 ` davek at gcc dot gnu dot org
2010-04-13 6:01 ` davek at gcc dot gnu dot org
2010-04-23 16:10 ` rguenth at gcc dot gnu dot org
2010-04-23 16:13 ` davek at gcc dot gnu dot org
2010-04-24 2:46 ` sherpya at netfarm dot it
2010-04-27 2:23 ` davek at gcc dot gnu dot org
2010-04-27 2:24 ` davek at gcc dot gnu dot org
2010-04-27 2:25 ` davek at gcc dot gnu dot org
2010-04-27 2:27 ` davek at gcc dot gnu dot org
2010-06-04 14:33 ` ro at gcc dot gnu dot org
2010-06-14 10:38 ` davek at gcc dot gnu dot org
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=20100412165552.13506.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@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).