On Tue, 22 Apr 2014 08:45:31 + (UTC)
Martin Vaeth wrote:
> Ryan Hill wrote:
> >
> > One thing I forgot to mention - LTO can also have detrimental effect on
> > certain architectures. On some (eg. ppc), performance can actually
> > be degraded due to increased register pressure.
>
> If this
On Tue, 22 Apr 2014 11:10:19 -0700
Matt Turner wrote:
> > One thing I forgot to mention - LTO can also have detrimental effect on
> > certain architectures. On some (eg. ppc), performance can actually be
> > degraded due to increased register pressure. On others like alpha it's
> > questionable
On Mon, Apr 28, 2014 at 5:46 PM, Andrew Savchenko wrote:
> Hello,
>
> On Sun, 27 Apr 2014 07:23:11 -0400 Rich Freeman wrote:
>> And yet, in the same paragraph you mention -O3, which is
>> tantamount to just setting a flag and walking away. That turns
>> on 14 things you probably don't really need
Hello,
On Sun, 27 Apr 2014 07:23:11 -0400 Rich Freeman wrote:
> And yet, in the same paragraph you mention -O3, which is
> tantamount to just setting a flag and walking away. That turns
> on 14 things you probably don't really need.
Why 14 things? According to gcc-4.8.2 manual -O3 enables the
fo
Hello,
On Sun, 27 Apr 2014 07:34:05 +0700 C. Bergström wrote:
[...]
> Not to be a smart-ass, but will someone start a thread on global
> PGO (profile guided optimizations) next? imho it would be
> interesting and great to have some general training data already
> contributed next to the ebuilds. F
>should not cause any issues (provided compilation goes through).
There are few packages which compile fine but break something (I remember
some x11-library from bugzilla that broke xorg-server), but generally I
agree with you.
One annoying package is 64bit firefox, which can easily eat up to 15GB
C. Bergström wrote:
> Can you name a single package that you use which receives a measurable
> benefit from LTO? (Just asking)
Like for every optimization flag, it is easy to construct particular
examples: It can help a lot if e.g. a user's string-helper library
is inlined. Concerning memory, it
On Sun 27 Apr 2014 08:40:08 PM EDT, "C. Bergström" wrote:
> In terms of general performance gains using LTO - The #1 candidate
> would be the linux kernel actually. See if anyone can get that to work ;)
Intel's Andi Kleen is working on it:
http://lkml.iu.edu/hypermail/linux/kernel/1404.0/03450.ht
On 04/27/2014 20:40, "C. Bergström" wrote:
> On those old SGI MIPS machines use MIPSPro. It had better (LTO/whole
> program) optimizations than GCC more than 10 years ago (imho and gcc may
> have caught up now in 4.9). Just add the -ipa flag and test. In fairness
> there is primarily 3 limitations
On 04/28/14 06:14 AM, Joshua Kinard wrote:
On 04/27/2014 19:08, Rich Freeman wrote:
On Sun, Apr 27, 2014 at 6:56 PM, Joshua Kinard wrote:
My curiosity, as I have not attempted LTO yet on any machine, is what are
the RAM requirements? Is it a hard limit, wherein the compiler simply fails
if th
On 04/27/2014 19:08, Rich Freeman wrote:
> On Sun, Apr 27, 2014 at 6:56 PM, Joshua Kinard wrote:
>>
>> My curiosity, as I have not attempted LTO yet on any machine, is what are
>> the RAM requirements? Is it a hard limit, wherein the compiler simply fails
>> if there isn't enough RAM, or does it
On Sun, Apr 27, 2014 at 6:56 PM, Joshua Kinard wrote:
>
> My curiosity, as I have not attempted LTO yet on any machine, is what are
> the RAM requirements? Is it a hard limit, wherein the compiler simply fails
> if there isn't enough RAM, or does it just start hitting swap real hard?
It just all
On 04/26/2014 20:34, "C. Bergström" wrote:
> On 04/27/14 02:58 AM, Martin Vaeth wrote:
>> Rich Freeman wrote:
>>> FWIW the list of packages I have issues with include:
>> Not sure whether this is the right place to post it.
> It's interesting to see that rather lengthy list. From a compiler engine
On 04/27/2014 07:23, Rich Freeman wrote:
> On Sat, Apr 26, 2014 at 10:37 PM, "C. Bergström"
> wrote:
>> #2 The only reference to anything which the compiler could impact is
>> "Use Boyer-Moore (and unroll its inner loop a few times)." Finding out which
>> flag controls that for ${CC} would have so
On Sun, Apr 27, 2014 at 7:41 AM, "C. Bergström"
wrote:
> On 04/27/14 06:23 PM, Rich Freeman wrote:
>> And yet, in the same paragraph you mention -O3, which is tantamount to
>> just setting a flag and walking away. That turns on 14 things you
>> probably don't really need.
>
> I was trying to give
On 04/27/14 06:23 PM, Rich Freeman wrote:
On Sat, Apr 26, 2014 at 10:37 PM, "C. Bergström"
wrote:
#2 The only reference to anything which the compiler could impact is
"Use Boyer-Moore (and unroll its inner loop a few times)." Finding out which
flag controls that for ${CC} would have some import
On Sat, Apr 26, 2014 at 10:37 PM, "C. Bergström"
wrote:
> #2 The only reference to anything which the compiler could impact is
> "Use Boyer-Moore (and unroll its inner loop a few times)." Finding out which
> flag controls that for ${CC} would have some importance. It's almost
> certainly combined
On 04/27/14 09:14 AM, Alex Xu wrote:
On 26/04/14 08:34 PM, "C. Bergström" wrote:
Pragmatically nobody gives a f* if grep has been optimized to the max
since it's usually not the bottleneck.
http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
My point about grep + LTO sti
On 26/04/14 08:34 PM, "C. Bergström" wrote:
> Pragmatically nobody gives a f* if grep has been optimized to the max
> since it's usually not the bottleneck.
http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
signature.asc
Description: OpenPGP digital signature
On Sat, Apr 26, 2014 at 3:58 PM, Martin Vaeth wrote:
> I have not always tested whether filtering -fwhole-program
> alone would be sufficient, but in many cases I did, and
> usually it was not sufficient.
Well, there is certainly something going on here, because...
> app-arch/bzip2 +flto*
This
On 04/27/14 02:58 AM, Martin Vaeth wrote:
Rich Freeman wrote:
FWIW the list of packages I have issues with include:
Not sure whether this is the right place to post it.
It's interesting to see that rather lengthy list. From a compiler
engineer perspective I'd like to toss in my opinion
-
Rich Freeman wrote:
>
> FWIW the list of packages I have issues with include:
Not sure whether this is the right place to post it.
Anyway, here is my filter file.
I remember now that almost everything using cmake and
related tools failed (e.g. practically all of kde-base, dev-qt).
Meanwhile I ha
On Sat, Apr 26, 2014 at 11:00 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>> It does make sense to filter the flag when it is known to
>> not work.
>
> This would be the best solution of course: Recommend LTO and
> filter every occassion which breaks. But currently this is
> not realistic, beca
Rich Freeman wrote:
>
> I tend to agree. I've been using stable gcc with -flto in my CFLAGS
> for a while now with only isolated problems.
I wouldn't call these problems isolated:
My current exception file has 340 lines, some of them containing
wildcards, and it has a tendency to grow.
For compa
Michał Górny wrote:
>
> Dnia 2014-04-22, o godz. 08:45:31
> Martin Vaeth napisa=B3(a):
>
>> On the other hand, if upstream tests and supports LTO, it should
>> be communicated to the user somehow that this is the case.
>> The same dilemma applies to some other CFLAGS which should not be
>> used i
On Sat, Apr 26, 2014 at 6:23 AM, Michał Górny wrote:
>
> As far as I understand, the LTO concept is suited well for most
> programs, though the results can vary. I agree that in the early stage
> many packages may be unhappy about it but as far as I understand, once
> it is more widespread only a
Dnia 2014-04-22, o godz. 08:45:31
Martin Vaeth napisał(a):
> On the other hand, if upstream tests and supports LTO, it should
> be communicated to the user somehow that this is the case.
> The same dilemma applies to some other CFLAGS which should not be
> used in general but only if the code is
> One thing I forgot to mention - LTO can also have detrimental effect on
> certain
> architectures. On some (eg. ppc), performance can actually be degraded due to
> increased register pressure. On others like alpha it's questionable if it'll
> even work at all...
Worked for me on alpha, at lea
Ryan Hill wrote:
>
> One thing I forgot to mention - LTO can also have detrimental effect on
> certain architectures. On some (eg. ppc), performance can actually
> be degraded due to increased register pressure.
If this really is the case it is not the problem of LTO but
of the optimizer: If the
On Sun, 20 Apr 2014 21:14:51 -0600
Ryan Hill wrote:
> Hey all,
>
> As more and more packages are starting to add LTO flags automatically through
> their build systems, I thought I'd point out a couple things:
>
> - LTO utterly destroys debug info. Flags like -g are incompatible with LTO.
>
>
30 matches
Mail list logo
