On 04/28/2010 12:33 AM, Alfred M. Szmidt wrote:
1) The back-and-forth is too much for casual contributors. If it is
more effort to do the legal work than to submit the first patch,
then they will never submit any patch at all.
Please do not exaggerate, if people have time for threads
2010/4/29 Jan Hubicka :
>> > On 4/28/10 10:26 , Manuel López-Ibá?ez wrote:
>> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
>> > and it is just for solving scaling issue of large program.(These two
>> > options do look similar :-). I shall try next.
>> > >>>
On Thu, Apr 29, 2010 at 6:11 AM, Dave Korn
wrote:
> On 26/04/2010 10:46, Richard Guenther wrote:
>> On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn wrote:
>
>>> If I understand correctly, what we farm out to gold/lto-plugin is the task
>>> of identifying a) which archive members are required to be pul
> 2010/4/29 Jan Hubicka :
> >> > On 4/28/10 10:26 , Manuel López-Ibá?ez wrote:
> >> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr
> >> > and it is just for solving scaling issue of large program.(These two
> >> > options do look similar :-). I shall try next.
On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther
wrote:
> Yes - that would be basically a linker plugin without plugin support.
> And I'd go even further and have LD provide a complete symbol
> resolution set like we get from the gold linker-plugin.
>
> That wouldn't help for old or non-gnu LDs
On Thu, Apr 29, 2010 at 11:19 AM, Steven Bosscher wrote:
> On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther
> wrote:
>> Yes - that would be basically a linker plugin without plugin support.
>> And I'd go even further and have LD provide a complete symbol
>> resolution set like we get from the g
> Indeed, looking at GCC 4.5 there's no cstore expander for floating-point
> variables. Maybe you can make a patch! :-)
>
yes, it seems gcc always generates set/compare/jump/set sequence,
then optimizes it out in if-convert pass. Maybe it was left behind by
early mips1, which has no conditional mo
> Well, we'd then need to re-architect the symbol merging and
> LTO unit read-in to properly honor linking semantics (drop
> a LTO unit from an archive if it doesn't resolve any unresolved
> symbols). I don't know how easy that will be, but it shouldn't
> be impossible at least.
We also should ke
Richard Guenther writes:
> Well, we'd then need to re-architect the symbol merging and
> LTO unit read-in to properly honor linking semantics (drop
> a LTO unit from an archive if it doesn't resolve any unresolved
> symbols). I don't know how easy that will be, but it shouldn't
> be impossible a
Jakub Jelinek writes:
> The branch is now frozen and all checkins until after the final release
> of GCC 4.4.4 require explicit RM approval.
>
> If all goes well, I'd like to release 4.4.4 next week.
I've got a couple of patches I might backport to the 4.4 branch after it
is unfrozen again, but
This URL
http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/tree-ssa-alias.c?annotate=155646
which tries to annotate the latest revision of tree-ssa-alias.c on 4.4
branch gives
An Exception Has Occurred
Python Traceback
Traceback (most recent call last):
File "/usr/lib/python2.3/site-p
2010/4/29 Jan Hubicka :
>> Well, we'd then need to re-architect the symbol merging and
>> LTO unit read-in to properly honor linking semantics (drop
>> a LTO unit from an archive if it doesn't resolve any unresolved
>> symbols). I don't know how easy that will be, but it shouldn't
>> be impossible
> 2010/4/29 Jan Hubicka :
> >> Well, we'd then need to re-architect the symbol merging and
> >> LTO unit read-in to properly honor linking semantics (drop
> >> a LTO unit from an archive if it doesn't resolve any unresolved
> >> symbols). I don't know how easy that will be, but it shouldn't
> >> b
Hi,
I wrote a lengthy wiki page with step-by-step instructions and demos on
building/installing/using gcc 4.5.0 with Graphite under a non-root user
account (my test system only had gcc 3.4.5 installed). I think those
instructions could be useful to some users of gcc, so feel free to copy
them or
Just curious, what is the base line size of your comparison? Did you
turn on GC (-ffunction-sections -fdata-sections -Wl,--gc-sections)?
David
On Wed, Apr 28, 2010 at 2:44 AM, Bingfeng Mei wrote:
> Thanks, I will check what I can do with collect2. LTO
> seems to save 6-9% code size for applicati
GCC-4.5.0 and LLVM-2.7 were released recently. To understand
where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000
for x86/x86-64 and posted the comparison of it with the
previous GCC releases and LLVM-2.7.
Even benchmarking SPEC2000 takes a lot of time on the fastest
machine I
I turned on -ffunction-sections and compiled with -Os.
The size gain at -O2 is less though.
Bingfeng
> -Original Message-
> From: Xinliang David Li [mailto:davi...@google.com]
> Sent: 29 April 2010 17:17
> To: Bingfeng Mei
> Cc: Richard Guenther; gcc@gcc.gnu.org
> Subject: Re: LTO quest
On Thu, Apr 29, 2010 at 9:28 AM, Bingfeng Mei wrote:
> I turned on -ffunction-sections and compiled with -Os.
> The size gain at -O2 is less though.
Interesting.
Thanks,
David
>
> Bingfeng
>
>> -Original Message-
>> From: Xinliang David Li [mailto:davi...@google.com]
>> Sent: 29 April 2
> GCC-4.5.0 and LLVM-2.7 were released recently. To understand
> where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000
> for x86/x86-64 and posted the comparison of it with the
> previous GCC releases and LLVM-2.7.
>
> Even benchmarking SPEC2000 takes a lot of time on the fastest
Jan Hubicka wrote:
GCC-4.5.0 and LLVM-2.7 were released recently. To understand
where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000
for x86/x86-64 and posted the comparison of it with the
previous GCC releases and LLVM-2.7.
Even benchmarking SPEC2000 takes a lot of time on t
-- Forwarded message --
From: Diego Novillo
Date: Thu, Apr 29, 2010 at 7:05 PM
Subject: Re: [LTO] Open items in the ToDo list
To: Sandeep Soni
Cc: Andi Hellmund
Thanks Sandeep. Could you please add your proposal to the GCC wiki?
Creating a new wiki page is fairly easy. You ad
Hi everybody!
I am working on a gcc-pass which processes every statement using this code:
for (node = cgraph_nodes; node; node = node->next)
{
if (node->analyzed && cgraph_is_master_clone (node))
{
push_cfun (DECL_STRUCT_FUNCTION (node->decl));
FO
On 29 April 2010 19:25, Sandeep Soni wrote:
> I added the following page to the wiki.
>
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> Any comments/suggestions or ideas related to the project are welcome.
Hi Sandy,
It may be helpful to take a look to wiki pages of previous SoC
projects, such as
ht
Vladimir Makarov wrote:
Jan Hubicka wrote:
Seems like something sensitive for setup. In our daily benchmarking LTO
fatster on wupwise (2116 compared to 1600), and facerec is 2003
compared to
2041 (so about the same).
http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-ai-64/list.html
ht
On Thu, Apr 29, 2010 at 9:25 AM, Vladimir Makarov wrote:
> GCC-4.5.0 and LLVM-2.7 were released recently. To understand
> where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000
> for x86/x86-64 and posted the comparison of it with the
> previous GCC releases and LLVM-2.7.
>
> Eve
I have an 15-year old C program (which I didn't write) that compiles and
runs fine with SparcWorks cc on Sun SPARC with SunOS 5.10.
It compiles on CentOS 5 64-bit with gcc 4.1.2 but core dumps all over
the place.
Switching to 32-bit compile doesn't help much.
I did as much debugging as I cou
On Thu, Apr 29, 2010 at 8:25 PM, Brian Hill wrote:
> I have an 15-year old C program (which I didn't write) that compiles and
> runs fine with SparcWorks cc on Sun SPARC with SunOS 5.10.
>
> It compiles on CentOS 5 64-bit with gcc 4.1.2 but core dumps all over the
> place.
>
> Switching to 32-bit
Xinliang David Li wrote:
On Thu, Apr 29, 2010 at 9:25 AM, Vladimir Makarov wrote:
GCC-4.5.0 and LLVM-2.7 were released recently. To understand
where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000
for x86/x86-64 and posted the comparison of it with the
previous GCC releases
On Thursday 29 April 2010 20:35:23 Steven Bosscher wrote:
> The standard 1st questions are:
> 1) Did you compile with -Wall -Wextra and solve all warnings?
> 2) Did you try with -fno-strict-aliasing?
for legacy code, the '-fwrapv' could be helpful.
>>
>
> Thanks for the comments. FDO will probably improve SPEC2000 score.
> Although it is not obvious for some tests because the train data sets for
> them are different from the reference data sets and it might actually
> mislead the compiler.
>
> FDO is important for optimizations where all p
Xinliang David Li wrote:
Thanks for the comments. FDO will probably improve SPEC2000 score.
Although it is not obvious for some tests because the train data sets for
them are different from the reference data sets and it might actually
mislead the compiler.
FDO is important for optimizations
Point well put. The benchmark suite should have good mixture of
programs with different sizes. SPEC2k programs cluster at the lower
end of the spectrum though.
David
On Thu, Apr 29, 2010 at 12:43 PM, Vladimir Makarov wrote:
> Xinliang David Li wrote:
>>>
>>> Thanks for the comments. FDO will pr
Hi,
I am looking at the arm-rtems test results for the
trunk and noticing that most failures appear to be
for neon tests.
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l
2203
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/ | wc -l
1986
http://gcc.gnu.org/ml/gcc-testresults/2010-
> Thanks for the comments. FDO will probably improve SPEC2000 score.
> Although it is not obvious for some tests because the train data sets
> for them are different from the reference data sets and it might
> actually mislead the compiler.
There are several studies on the topic and it is
BTW we are also tracking SPEC2k6 with and without LTO (not FDO runs)
http://gcc.opensuse.org/SPEC/CINT/sb-barbella.suse.de-ai-64/recent.html
http://gcc.opensuse.org/SPEC/CINT/sb-barbella.suse.de-head-64-2006/recent.html
not all 2k6 tests pass with LTO so it will need a bit care to compare results
On Thu, Apr 29, 2010 at 2:27 PM, Jan Hubicka wrote:
>> Thanks for the comments. FDO will probably improve SPEC2000 score.
>> Although it is not obvious for some tests because the train data sets
>> for them are different from the reference data sets and it might
>> actually mislead the compiler.
I noticed eon's peak options do not include FDO, is that intended?
David
On Thu, Apr 29, 2010 at 2:27 PM, Jan Hubicka wrote:
>> Thanks for the comments. FDO will probably improve SPEC2000 score.
>> Although it is not obvious for some tests because the train data sets
>> for them are different
On Thu, Apr 29, 2010 at 11:27 PM, Jan Hubicka wrote:
> It would be interesting to know if same improvement happens with LTO and if
> not what LIPO does. I will unbreak vortex on our tester.
Perhaps you can add a LIPO tester? It looks like a very interesting
and promising approach.
Ciao!
Steven
> I noticed eon's peak options do not include FDO, is that intended?
I think it is just bug in page header, but I will double check.
Base and peak should match otherwise.
Honza
Thanks for the suggestion. Raksit currently is busy with merging trunk
changes back to lw-ipo branch which can be a daunting task. After that
this can be done. (Our internal release is based on 4.4).
David
On Thu, Apr 29, 2010 at 2:38 PM, Steven Bosscher wrote:
> On Thu, Apr 29, 2010 at 11:27 P
On Thu, Apr 29, 2010 at 12:25:15PM -0400, Vladimir Makarov wrote:
>
> Currently Graphite gives small improvements on x86 (one exception is
> 2% for peak x86 SPECFP2000) and mostly degradation on x86_64 (with
> maximum one more than 10% for SPECFP2000 because of big degradations
> on mgrid and
> Thanks for the suggestion. Raksit currently is busy with merging trunk
> changes back to lw-ipo branch which can be a daunting task. After that
> this can be done. (Our internal release is based on 4.4).
I must say that LIPO is something I always intend to look into but didn't
seriously find ti
2010/4/30 Jan Hubicka :
>> Thanks for the suggestion. Raksit currently is busy with merging trunk
>> changes back to lw-ipo branch which can be a daunting task. After that
>> this can be done. (Our internal release is based on 4.4).
>
> I must say that LIPO is something I always intend to look int
Snapshot gcc-4.5-20100429 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100429/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> 2010/4/30 Jan Hubicka :
> >> Thanks for the suggestion. Raksit currently is busy with merging trunk
> >> changes back to lw-ipo branch which can be a daunting task. After that
> >> this can be done. (Our internal release is based on 4.4).
> >
> > I must say that LIPO is something I always intend
On Thu, 29 Apr 2010, Joel Sherrill wrote:
> Hi,
>
> I am looking at the arm-rtems test results for the
> trunk and noticing that most failures appear to be
> for neon tests.
>
> [j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l
> 2203
> [j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon
2010/4/30 Jan Hubicka :
> Yep, I read that page (and saw some of implementation too). Just was not able
> to follow the precise feature set of LIPO (i.e. if it gets better SPEC results
> than LTO+FDO then why)
OK, that's an interesting question. The first question (if...) is
something you'll have
On Thu, Apr 29, 2010 at 4:03 PM, Jan Hubicka wrote:
>> 2010/4/30 Jan Hubicka :
>> >> Thanks for the suggestion. Raksit currently is busy with merging trunk
>> >> changes back to lw-ipo branch which can be a daunting task. After that
>> >> this can be done. (Our internal release is based on 4.4).
> Date: Thu, 29 Apr 2010 08:55:56 +0200 (CEST)
> From: "Jonas Paulsson"
> It feels good to know that the widening mults issue has been
> resolved
Yes, nice, and as late as last week too, though the patch was
from February.
> as
> it was a bit of a disapointment I noted the erratic behaviour wit
On Thu, Apr 29, 2010 at 11:01 PM, Manuel López-Ibáñez
wrote:
> On 29 April 2010 19:25, Sandeep Soni wrote:
>> I added the following page to the wiki.
>>
>> http://gcc.gnu.org/wiki/GimpleFrontEnd
>>
>> Any comments/suggestions or ideas related to the project are welcome.
>
> Hi Sandy,
>
> It may b
HI:
There is comment on lui_movf in mips.md like following,
;; because we don't split it. FIXME: we should split instead.
I can split it into a move and a condmove(movesi_on_cc) insns , like
(define_split
[(set (match_operand:CC 0 "d_operand" "")
(match_operand:CC 1 "fcc_reload_opera
51 matches
Mail list logo
