Re: Subversion Status
On 7 April 2010 23:52, Andrew John Hughes wrote: > Has anyone else seen this error from trunk? > > $ svn status > svn: Error at entry 15 in entries file for 'gcc/testsuite/g++.dg/warn': > svn: Bogus date Then entries file for that directory is perhaps in g++.dg/.svn/. Have you tried deleting all of g++.dg/ ? A fresh checkout? Perhaps a hard-drive glitch? Cheers, Manuel. > > Even if I delete the gcc/testsuite/g++.dg/warn tree, an update brings > the error back. > > svn is 1.6.9. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >
Posao
AGENT ZA NEKRETNINE Opis kompanije: Agencija za promet nekretnina Opis posla: Agenciji za promet nekretnina ZIP EUROPE potrebni agenti prodaje sa ili bez radnog iskustva. Ponuda (bonusi, povlastice): Rad je na uz fiksnu platnu i procenat uz stimulaciju u zavisnosti od ucinka (50% agencijske provizije) Zahtevi: - nezaposlen - osnovno poznavanje rada na racunaru - sposobnost za timski rad - kreativnost Test sposobnosti mozeto obaviti na http://www.zipeurope.uk.pn Kandidati koji pokazu dobre rezultate na testu bice kontaktirani.
WHOPR bootstrap, when/how?
Hello, I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled. Not sure what happened, other than that my machine ran out of memory. I guess this is kind-of expected, but it made me wondering how much work, and what exactly, remains to be done before bootstrapping with WHOPR enabled is possible. Is this even a goal? It'd be nice if we can track this on a wiki page, and I'd make one myself except that I have no idea where GCC WHOPR stands at the moment :-) Hope someone can explain the status, and perhaps the plan... Ciao! Steven
Re: WHOPR bootstrap, when/how?
On Thu, Apr 8, 2010 at 12:32 PM, Steven Bosscher wrote: > Hello, > > I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled. > Not sure what happened, other than that my machine ran out of memory. > I guess this is kind-of expected, but it made me wondering how much > work, and what exactly, remains to be done before bootstrapping with > WHOPR enabled is possible. Is this even a goal? > > It'd be nice if we can track this on a wiki page, and I'd make one > myself except that I have no idea where GCC WHOPR stands at the moment > :-) > > Hope someone can explain the status, and perhaps the plan... Well. The status is that only gold supports static archives at the moment (and thus is able to LTO libbackend.a). Also WHOPR is largely disfunctional ATM. The goal is to replace the -combine mode with LTOing the host binaries at least (eventually even installing static target libs with LTO bytecode included so you can inline from libgfortran for example). It's been some time since I last tried bootstrapping with LTO enabled though ... Richard. > Ciao! > Steven >
Re: why mult generated for unsigned int multiply on mips?
> It would, however, be nice if you actually posted an answer to your > (now solved) question. That way, any casual reader may learn something > new. > Sorry for the unintentional offense, here comes the method: for 2's complement binary number x31x30...x0, unsigned value U = 2^(31)*x31 + 2^(30)*x30 + ... + 2^(0)*x0 signed value S = - 2^(31)*x31 + 2^(30)*x30 + ... + 2^(0)*x0 say V = 2^(30)*x30 + ... + 2^(0)*x0, and s = x31 so, S = U - 2^(32)*s. now think about two number U1, U2, the corresponding signed value are S1, S2. S1 * S2 = (U1-2^32 *s1 ) * (U2-2^32 *s2) = U1*U2 - 2^32*s2*U1 - 2^32*s1*U2 + 2^64*s1*s2 It's easy to prove that the lower 32 bit of S1*S2 is determined by the lower part of U1*U2. Maybe this is the reason gcc can safely use mult for unsigned multiplication for mips. Hope this is right and it's hard to edit equations in plain text -_- -- Best Regards.
Re: why mult generated for unsigned int multiply on mips?
Amker.Cheng wrote: now think about two number U1, U2, the corresponding signed value are S1, S2. S1 * S2 = (U1-2^32 *s1 ) * (U2-2^32 *s2) = U1*U2 - 2^32*s2*U1 - 2^32*s1*U2 + 2^64*s1*s2 It's easy to prove that the lower 32 bit of S1*S2 is determined by the lower part of U1*U2. Maybe this is the reason gcc can safely use mult for unsigned multiplication for mips. Hope this is right and it's hard to edit equations in plain text -_- Yes this is right, it's well known that for multiplication of 32 x 32 => 32, unsigned and signed are equivalent except for overflow considerations. The only reason a processor would have separate signed and unsigned single length multiplication instructions is if there are overflow traps, or overflow or other arithmetic flags set. In other words the same situation as for addition/subtraction. Note that for a double length result multplication, the results are quite different. Consider -1 * -1, the result is +1 signed, so * signed = _0001 but * unsigned is FFFE_0001 Note that as we expect, the low order 32 bits is the same. For division, even the single length quotient is different, so there you need two instructions, or if the processor has only unsigned division, then you have to fiddle to get a signed result.
Re: WHOPR bootstrap, when/how?
On Thu, Apr 8, 2010 at 06:32, Steven Bosscher wrote: > I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled. > Not sure what happened, other than that my machine ran out of memory. > I guess this is kind-of expected, but it made me wondering how much > work, and what exactly, remains to be done before bootstrapping with > WHOPR enabled is possible. Is this even a goal? It was. Unfortunately,work on it stopped last year and it is unlikely that I will be assigned to this again. I still have some personal interest on the feature, but given time restrictions, we should make contingency plans. Perhaps the easiest option is to remove the feature. WHOPR does not represent a lot of code over the basic LTO framework, so this should be relatively easy and non-intrusive. If we do keep it, my expectation was to convert WHOPR into a profile-guided feature, much like what LIPO does. Instead of trying to statically decide what TUs to compile together, we generate gimple bytecode for all TUs, then link normally (without combining them) and run the binary with profile generation enabled. During the second compilation, we use the profile generated to decide what TUs to link together. This avoids the complexity we currently have with WHOPR, which needs to re-exec itself and make static decisions. Additionally, removing the current WHOPR code will not affect that plan. The first target I would shoot for, however, is to replace -combine with -flto. Diego.
Re: WHOPR bootstrap, when/how?
On Thu, Apr 08, 2010 at 09:13:45AM -0400, Diego Novillo wrote:
>
> Perhaps the easiest option is to remove the feature. WHOPR does not
> represent a lot of code over the basic LTO framework, so this should
> be relatively easy and non-intrusive.
>
> The first target I would shoot for, however, is to replace -combine with
> -flto.
I am bit confused by this last sentence. Isn't it already the case in
gcc 4.5 that using -flto both at compile and at link times (usually a
trivial way to do that might be "make CC='gcc-4.5 -flto -O2'" or
something similar) is practically enough to replace the -combine flag?
In other words, what are the real reasons to keep -combine in gcc 4.5?
I feel it is becoming a deprecated feature (of course, it seems
that the major difference is that -combine makes most name becoming
local symbols, while -flto keeps all global names as global symbols
from the linking point of view).
So what are the real use cases of -combine not covered by -flto ?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: WHOPR bootstrap, when/how?
On Thu, 8 Apr 2010, Diego Novillo wrote: > On Thu, Apr 8, 2010 at 06:32, Steven Bosscher wrote: > > > I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled. > > Not sure what happened, other than that my machine ran out of memory. > > I guess this is kind-of expected, but it made me wondering how much > > work, and what exactly, remains to be done before bootstrapping with > > WHOPR enabled is possible. Is this even a goal? > > It was. Unfortunately,work on it stopped last year and it is unlikely > that I will be assigned to this again. I still have some personal > interest on the feature, but given time restrictions, we should make > contingency plans. > > Perhaps the easiest option is to remove the feature. WHOPR does not > represent a lot of code over the basic LTO framework, so this should > be relatively easy and non-intrusive. > > If we do keep it, my expectation was to convert WHOPR into a > profile-guided feature, much like what LIPO does. Instead of trying > to statically decide what TUs to compile together, we generate gimple > bytecode for all TUs, then link normally (without combining them) and > run the binary with profile generation enabled. > > During the second compilation, we use the profile generated to decide > what TUs to link together. This avoids the complexity we currently > have with WHOPR, which needs to re-exec itself and make static > decisions. > > Additionally, removing the current WHOPR code will not affect that plan. I think we're going to fix WHOPR, not remove it. The overall idea is sane and we can still use profile-feedback to drive its partitioning decisions. > The first target I would shoot for, however, is to replace -combine with > -flto. Indeed. My first target is to get infrastructure ready to fix the TBAA issues. Richard.
Error while building GCC 4.5 (MinGW)
Hi, I am trying to build a toolchain for gcc-4.5-20100401 snapshot. The linux toolchain was built successfully as expected. However, on building the mingw toolchain, it generated the following error while configuring gcc:- =error checking for the correct version of the gmp/mpfr/mpc libraries... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. error The following commands were used to build the precision libraries. ./gmp-4.2.2/configure --host=mingw32 --target=mingw32 --build=i686-pc-linux-gnu --prefix=$prefix ./mpfr-2.3.1configure --host=mingw32 --target=mingw32 --build=i686-pc-linux-gnu --with-gmp=$prefix --prefix=$prefix ./mpc-0.8/configure --host=mingw32 --target=mingw32 --build=i686-pc-linux-gnu --with-gmp=$prefix --with-mpfr=$prefix --prefix=$prefix The LD_LIBRARY PATH was also exported to $PREFIX PATH. However, the error was not resolved. This error is due to the addition of MPC library dependency. Please let me know whether its a known problem OR I am missing anything while building the libraries? Regards, Brew
Re: Subversion Status
On 11:05 Thu 08 Apr , Manuel López-Ibáñez wrote: > On 7 April 2010 23:52, Andrew John Hughes wrote: > > Has anyone else seen this error from trunk? > > > > $ svn status > > svn: Error at entry 15 in entries file for 'gcc/testsuite/g++.dg/warn': > > svn: Bogus date > > Then entries file for that directory is perhaps in g++.dg/.svn/. Have > you tried deleting all of g++.dg/ ? A fresh checkout? Perhaps a > hard-drive glitch? Deleting g++.dg worked. I don't know how it became broken to begin with (all I did was update and I only usually work in libjava) but sorry for the noise. I saw mention of a git mirror (http://gcc.gnu.org/wiki/GitMirror) so may switch to that :-) > > Cheers, > > Manuel. > > > > > Even if I delete the gcc/testsuite/g++.dg/warn tree, an update brings > > the error back. > > > > svn is 1.6.9. > > -- > > Andrew :-) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and the OpenJDK > > http://www.gnu.org/software/classpath > > http://openjdk.java.net > > > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: WHOPR bootstrap, when/how?
On Thu, Apr 8, 2010 at 09:25, Basile Starynkevitch wrote: > I am bit confused by this last sentence. Isn't it already the case in > gcc 4.5 that using -flto both at compile and at link times (usually a > trivial way to do that might be "make CC='gcc-4.5 -flto -O2'" or > something similar) is practically enough to replace the -combine flag? It should be, yes. It still needs to be done and make sure that no regressions are introduced. > So what are the real use cases of -combine not covered by -flto ? I don't know. I haven't checked. In theory, -flto is already a superset of -combine. Diego.
Re: [alpha] Wrong code produced at -Os, -O2, and -O3
On Thu, Apr 8, 2010 at 2:16 AM, Uros Bizjak wrote: > On Wed, Apr 7, 2010 at 8:38 PM, Matt Turner wrote: > >> I was rewriting the Alpha sched_find_first_bit implementation for the >> Linux Kernel, and in the process I think I've come across a gcc bug. > > [...] > >> Thanks. Let me know what I can do to help further. > > Please fill a Bugzilla bugreport with your problem. Otherwise, it will > be lost in the mailing lists. > > Uros. > Sure. Thanks for the email. I've filed it in Bugzilla, with as small a test case as I can. Thanks! Matt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
Making BB Reorder Smarter for -Os
Bugzilla 41004 calls for a more -Os-friendly algorithm for BB Reorder, and I'm hoping I can meet this challenge. But I need your help! If you have any existing ideas or thoughts that could help me get closer to a sensible heuristic sooner, then please post them to this list. In the mean time, here's my progress so far: My first thought was to limit BB Reorder to hot functions, as identified by gcov, so we could get maximum execution time benefit for minimised code size impact. Based on benchmarking I've done so far, this looks to be a winner, but it only works when profile data is available. Without profile data, we face two main problems: 1) We cannot easily estimate how many times we will execute our more efficient code-layout, so we can't do an accurate trade-off versus the code size increase. 2) The traces that BB Reorder constructs will be based on static branch prediction, rather than true dynamic flows of execution, so the new layout may not be the best one in practice. We can address #1 by tagging functions as hot (using attributes), but that may not always be possible and it does not guarantee that we will get minimal codesize increases, which is the main aim of this work. I'm not sure how #2 can be addressed, so I'm planning to sidestep it completely, since the problem isn't really the performance pay-off but the codesize increase that usually comes with each new layout of a function that BB Reorder makes. My current plan is to characterise a function within find_traces() (looking at things like the number of traces, edge probabilities and frequencies, etc) and only call connect_traces() to effect the reordering change if these characteristics suggest that minimal code disruption will occur and/or maximum performance pay-off. Thanks for reading and I look forward to your input! Cheers, Ian
GSoC idea — Implementing a C Compiler for EFI Byte Code using GCC
Hello all, I submit my proposal “Implementing a C Compiler for EFI Byte Code using GCC”. Welcome your comments, if you are interested in the topic. My proposal URL is http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/yi_hong/t127073387438 thanks yi-hong
Re: WHOPR bootstrap, when/how?
> It was. Unfortunately,work on it stopped last year and it is unlikely > that I will be assigned to this again. I still have some personal > interest on the feature, but given time restrictions, we should make > contingency plans. > > Perhaps the easiest option is to remove the feature. WHOPR does not > represent a lot of code over the basic LTO framework, so this should > be relatively easy and non-intrusive. I would preffer completing this feature rather then removing it. I plan to work on cleaning up the basic infrastructure (i.e. making LTRANS stage working correctly and really read in what optimizations at WPA stage decided) during this stage1. (This week my thesis really converged, I should submit in two weeks or so, so this seems realistic plan ;) Here is brief outline what I would like to do: Main problem of current WHOPR implementation is that is is quite broken in a way WPA->LTRANS streaming works. We don't do anything but inlining at WPA and we don't stream out result if IP propagation to LTRANS and instead LTRANS re-do everything locally. So we need: 1) Update visibility stuff in callgraph so it works on partial units in LTRANS (i.e. we should know that some function body was available, is in other LTRANS unit and we do have following summary knowledge about (such as IPA-PTA sets) that are useful for compilation of current unit) 2) Fix WPA partitioning versus to clones, it is completely broken 3) Make callgraph streamer to stream callgraph with results of IPA optimization. That is we need, for example, to stream inline_failed reasons from WPA->LTRANS, but we don't need to stream it in LTO. At the moment we stream it always. On the other hand we never stream info about clones that we must stream in WPA->LTRANS too. 4) Fix passmanager. The stuff should work as follows: Compilation: Early optimization, analysis of all IPA passes WPA Propagation of all IPA passes Ltrans Transofrmation of all IPA passes rest of compilation Currently we do something like this: Compilation: Early optimization, analysis of all IPA passes WPA Propagation for inliner alone Ltrans Throw away inlining decisions made Do analysis, propagation and transformation of all IPA pases rest of compilation As we have read/write methods for summaries, we need read/write methods for optimization summaries and we need some PM cleanups to integrate it better with compilation process. 5) To get some benefits we need to get back the parallel compilation of ltrans etc. etc. So as time allows, I would like to work on these items pretty much in this order. Of course I would be happy if someone beats me. > > If we do keep it, my expectation was to convert WHOPR into a > profile-guided feature, much like what LIPO does. Instead of trying > to statically decide what TUs to compile together, we generate gimple > bytecode for all TUs, then link normally (without combining them) and > run the binary with profile generation enabled. > > During the second compilation, we use the profile generated to decide > what TUs to link together. This avoids the complexity we currently > have with WHOPR, which needs to re-exec itself and make static > decisions. Well, I think this is independent. It makes a lot of sense to make profiling to work in a way so instrumentation happens at linktime with LTO and we can read stuff back. This is relatively easy to do: we need to rewrite profiling pass to work on SSA (that is easy and desirable anyway and on my TODO for a while). Then we need to split gcov and -fprofile-generate profiling passes. Gcov needs to happen early since early optimization will optimize out dead code and we want to count it. Profile generation needs to be done late since we want it at linktime. Then we will be able to do profiling at LTO. With WHOPR I expect situation to be bit funnier, since one does not have the function bodies and thus it is difficult to read in the profile, get callgraph profile and do something about it. I guess one solution is to add callgraph profiling into our instrumentation or make it possible to read CFG of each function at WHOPR stage and do profile read. Didn't had much time to think this over. > > Additionally, removing the current WHOPR code will not affect that plan. > > The first target I would shoot for, however, is to replace -combine with > -flto. :) We need debug info and hammer out all bugs of course! I would also like to see possiblity to LTO bootstrap without gold and possibility to not generate assembly into LTO .o files. In the typical use where one builds app with LTO (such as bootstrap) this just slow down everything approximately twice that is IMO silly. Honza > > > Diego.
Re: WHOPR bootstrap, when/how?
> Well, I think this is independent. > It makes a lot of sense to make profiling to work in a way so instrumentation > happens at linktime with LTO and we can read stuff back. This is relatively > easy to do: we need to rewrite profiling pass to work on SSA (that is easy and > desirable anyway and on my TODO for a while). Then we need to split gcov and > -fprofile-generate profiling passes. Gcov needs to happen early since early > optimization will optimize out dead code and we want to count it. > Profile generation needs to be done late since we want it at linktime. > > Then we will be able to do profiling at LTO. > > With WHOPR I expect situation to be bit funnier, since one does not have > the function bodies and thus it is difficult to read in the profile, > get callgraph profile and do something about it. And as for profiling, I would hope WHOPR to be solution for building large application with whole program optimization. LIPO or any sort of profile driven partitioning is not that. Just very few users will bother with profiling, while LTO/WHOPR has chance to be transparent enough to be widely adopted. So I think tying WHOPR and profile feedback too close together is a mistake. Honza
Re: WHOPR bootstrap, when/how?
On 4/8/10 14:10 , Jan Hubicka wrote: > So I think tying WHOPR and profile feedback too close together is a mistake. Sorry, I didn't mean that. My intent is to make whopr/lto use profiling information if it is available. Much like we do with other optimization decisions. They transparently become more precise in the presence of profiling information. Diego.
Re: WHOPR bootstrap, when/how?
> On 4/8/10 14:10 , Jan Hubicka wrote: > > > So I think tying WHOPR and profile feedback too close together is a mistake. > > Sorry, I didn't mean that. My intent is to make whopr/lto use profiling > information if it is available. Much like we do with other optimization > decisions. They transparently become more precise in the presence of > profiling information. Both LTO and WHOPR now works with profiling pretty well (and I've switched our SPEC tester to use it http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-fdo-64-FDO/recent.html http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-fdo-64-FDO/index.html it was switched in November). I see now that GCC is failing, will investigate why. The anoyance is that you really need to compile twice since instrumentation happens at compilation stage and is also read at compilation stage and just streamed to .o files. It would be better to require re-linking only. On the other hand I think if user is is keen enough to use profile feedback and LTO, he is keen to do full recompilation too, so this is not the most important missing feature of LTO we need to deal with. Honza > > > Diego.
Re: WHOPR bootstrap, when/how?
> > On 4/8/10 14:10 , Jan Hubicka wrote: > > > > > So I think tying WHOPR and profile feedback too close together is a > > > mistake. > > > > Sorry, I didn't mean that. My intent is to make whopr/lto use profiling > > information if it is available. Much like we do with other optimization > > decisions. They transparently become more precise in the presence of > > profiling information. > > Both LTO and WHOPR now works with profiling pretty well (and I've switched ^ too much of market speach. WHOPR is not working well, profile feedback or not ;)
Re: WHOPR bootstrap, when/how?
On 4/8/10 14:30 , Jan Hubicka wrote: >>> On 4/8/10 14:10 , Jan Hubicka wrote: >>> So I think tying WHOPR and profile feedback too close together is a mistake. >>> >>> Sorry, I didn't mean that. My intent is to make whopr/lto use profiling >>> information if it is available. Much like we do with other optimization >>> decisions. They transparently become more precise in the presence of >>> profiling information. >> >> Both LTO and WHOPR now works with profiling pretty well (and I've switched > ^ too much of market speach. WHOPR is not working well, >profile feedback or not ;) Ah! I was going to say :) For WHOPR, the partitioning should be driven by profile info (if available). First, it should Just Work, of course. Diego.
Re: WHOPR bootstrap, when/how?
> On 4/8/10 14:30 , Jan Hubicka wrote: > >>> On 4/8/10 14:10 , Jan Hubicka wrote: > >>> > So I think tying WHOPR and profile feedback too close together is a > mistake. > >>> > >>> Sorry, I didn't mean that. My intent is to make whopr/lto use profiling > >>> information if it is available. Much like we do with other optimization > >>> decisions. They transparently become more precise in the presence of > >>> profiling information. > >> > >> Both LTO and WHOPR now works with profiling pretty well (and I've switched > >^ too much of market speach. WHOPR is not working well, > > profile feedback or not ;) > > Ah! I was going to say :) > > For WHOPR, the partitioning should be driven by profile info (if > available). First, it should Just Work, of course. Well, since we should be able to stream out the result of IPA propagation across whole program, the particular partitioning decision should not be that important (i.e. affecting the propagation in late compilation and possibly some simple IPA passes we might do before but don't at the moment). But yes, we should be able to get hot part of program into single closed partition or something like that to get some extra score. Honza > > > Diego.
Re: WHOPR bootstrap, when/how?
On 4/8/10 14:34 , Jan Hubicka wrote: >> On 4/8/10 14:30 , Jan Hubicka wrote: > On 4/8/10 14:10 , Jan Hubicka wrote: > >> So I think tying WHOPR and profile feedback too close together is a >> mistake. > > Sorry, I didn't mean that. My intent is to make whopr/lto use profiling > information if it is available. Much like we do with other optimization > decisions. They transparently become more precise in the presence of > profiling information. Both LTO and WHOPR now works with profiling pretty well (and I've switched >>>^ too much of market speach. WHOPR is not working well, >>> profile feedback or not ;) >> >> Ah! I was going to say :) >> >> For WHOPR, the partitioning should be driven by profile info (if >> available). First, it should Just Work, of course. > > Well, since we should be able to stream out the result of IPA propagation > across whole program, the particular partitioning decision should not be that > important (i.e. affecting the propagation in late compilation and possibly > some > simple IPA passes we might do before but don't at the moment). > > But yes, we should be able to get hot part of program into single closed > partition or something like that to get some extra score. Right. That's (in its most basic form) what LIPO does with the grouping model. David, what else does LIPO use the profiling information for? Diego.
Re: WHOPR bootstrap, when/how?
Diego, thanks for brining LIPO into discussion.
There is a common misunderstanding of LIPO. It is not about
partitioning, but about extending single module compilation scope to
multiple/cross module. For instance for a build with a.c, b.c, c.c,
and d.c, LIPO does not partition them into
{a.c b.c}
{c.c d.c}
but extend for instance a.c to include c.c (as auxilary module), so
there will be still 4 independent compilations instead of 2:
{a.c, c.c}
b.c
c.c
d.c
There will be a LIPO presentation in this year's CGO. LIPO has been
used successfully for very large applications. Another news is that
there is an effort to do LIPO with sampled FDO -- that means you don't
have to have the instrumentation step in order to use LIPO.
I want to use this opportunity to emphasize a couple of points:
1) people use IPO because they care about performance. However IPO
won't be that effective without FDO except for really small toy
programs.
2) on contrary to what many thinks, FDO is used in real life and the
process is not as horrible as people think
3) LIPO adds IPO capability into FDO almost seamlessly which makes it
really attractive and easy to adopt (esp when FDO is already used).
Thanks,
David
On Thu, Apr 8, 2010 at 11:37 AM, Diego Novillo wrote:
> On 4/8/10 14:34 , Jan Hubicka wrote:
>>> On 4/8/10 14:30 , Jan Hubicka wrote:
>> On 4/8/10 14:10 , Jan Hubicka wrote:
>>
>>> So I think tying WHOPR and profile feedback too close together is a
>>> mistake.
>>
>> Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
>> information if it is available. Much like we do with other optimization
>> decisions. They transparently become more precise in the presence of
>> profiling information.
>
> Both LTO and WHOPR now works with profiling pretty well (and I've switched
^ too much of market speach. WHOPR is not working well,
profile feedback or not ;)
>>>
>>> Ah! I was going to say :)
>>>
>>> For WHOPR, the partitioning should be driven by profile info (if
>>> available). First, it should Just Work, of course.
>>
>> Well, since we should be able to stream out the result of IPA propagation
>> across whole program, the particular partitioning decision should not be that
>> important (i.e. affecting the propagation in late compilation and possibly
>> some
>> simple IPA passes we might do before but don't at the moment).
>>
>> But yes, we should be able to get hot part of program into single closed
>> partition or something like that to get some extra score.
>
> Right. That's (in its most basic form) what LIPO does with the grouping
> model. David, what else does LIPO use the profiling information for?
>
>
> Diego.
>
Re: WHOPR bootstrap, when/how?
On Thu, Apr 8, 2010 at 14:53, Xinliang David Li wrote:
> Diego, thanks for brining LIPO into discussion.
>
> There is a common misunderstanding of LIPO. It is not about
> partitioning, but about extending single module compilation scope to
> multiple/cross module. For instance for a build with a.c, b.c, c.c,
> and d.c, LIPO does not partition them into
> {a.c b.c}
> {c.c d.c}
>
> but extend for instance a.c to include c.c (as auxilary module), so
> there will be still 4 independent compilations instead of 2:
>
> {a.c, c.c}
> b.c
> c.c
> d.c
Oh, right. That's what I was referring to, but I used bad
terminology, sorry. So, LIPO starts with the individual TUs and
decides to augment them using the available profile. WHOPR starts
with the whole callgraph and, using the same profile information,
needs to make the opposite and partition the TUs. In fact, it may
likely end up with fractions of TUs spread out (which does introduce
complications, as certain declarations need to be replicated).
Diego.
GSoC idea : Implementing a C Compiler for EFI Byte Code using GCC
Hello Robert and all, I have change the encoding from Big-5 to UTF-8 Is this in your means of wierd fonts?? I submit my proposal “Implementing a C Compiler for EFI Byte Code using GCC”. Welcome your comments, if you are interested in the topic. My proposal URL is http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/yi_hong/t127073387438 thanks. yi-hong
Re: GCC primary/secondary platforms?
On 07/04/2010 19:47, Tim Prince wrote: > Will there be a notification if and when C++ run-time will be ready to > test on secondary platforms, or will platforms like cygwin be struck > from the secondary list? What exactly are you talking about? Libstdc++-v3 builds just fine on Cygwin. > Our release criteria for the secondary platforms is: > > * The compiler bootstraps successfully, and the C++ runtime library > builds. > * The DejaGNU testsuite has been run, and a substantial majority of the > tests pass. We pass both those criteria with flying colours. What are you worrying about? cheers, DaveK
Coleção Outono / Iverno 2010 !!
<>
gcc-4.5-20100408 is now available
Snapshot gcc-4.5-20100408 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100408/ 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/gcc-4_5-branch revision 158139 You'll find: gcc-4.5-20100408.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100408.tar.bz2 C front end and core compiler gcc-ada-4.5-20100408.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100408.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100408.tar.bz2 C++ front end and runtime gcc-java-4.5-20100408.tar.bz2 Java front end and runtime gcc-objc-4.5-20100408.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100408.tar.bz2The GCC testsuite Diffs from 4.5-20100401 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC primary/secondary platforms?
On 4/8/2010 2:40 PM, Dave Korn wrote: On 07/04/2010 19:47, Tim Prince wrote: Will there be a notification if and when C++ run-time will be ready to test on secondary platforms, or will platforms like cygwin be struck from the secondary list? What exactly are you talking about? Libstdc++-v3 builds just fine on Cygwin. Our release criteria for the secondary platforms is: * The compiler bootstraps successfully, and the C++ runtime library builds. * The DejaGNU testsuite has been run, and a substantial majority of the tests pass. We pass both those criteria with flying colours. What are you worrying about? cheers, DaveK No one answered questions about why libstdc++ configure started complaining about mis-match in style of wchar support a month ago. Nor did I see anyone give any changes in configure procedure. Giving it another try at a new download today. -- Tim Prince
Re: GCC primary/secondary platforms?
On 09/04/2010 01:23, Tim Prince wrote: > No one answered questions about why libstdc++ configure started > complaining about mis-match in style of wchar support a month ago. I don't seem to have received it; can you post a link to the archive? > Nor > did I see anyone give any changes in configure procedure. Giving it > another try at a new download today. Well, nothing has changed, but then again I haven't seen anyone else complaining about this, so there's probably some problem in your build environment; let's see what happens with your fresh build. (I've built the 4.5.0-RC1 candidate without any complications and am running the tests right now.) cheers, DaveK
Re: GCC primary/secondary platforms?
Although the dscussion regarding libstdc++-v3 is likely germaine to various developers who are currently testing their changes and managing the ports that they're responsible for, it seems that this thread is venturing rather far from my initial query. I'm still wondering: Do GCC developers routinely test their patches on MIPS, ARM, and S390 platforms (for example)? I signed up for the 'cfarm' and don't see an S390 there, and some of the secondary targets look like they might be really SLOW? thanks, - Gary
Re: GCC primary/secondary platforms?
On 09/04/2010 03:49, Gary Funck wrote: > I'm still wondering: Do GCC developers routinely > test their patches on MIPS, ARM, and S390 platforms > (for example)? I signed up for the 'cfarm' and don't see > an S390 there, and some of the secondary targets > look like they might be really SLOW? Well, MIPS and ARM are well supported by simulators, which is how a lot of people test patches that are going to affect the core compiler and potentially have side effects on many platforms, e.g. when merging a big branch with some major new functionality to trunk. But very many patches are either clearly target-specific, or clearly generic enough or simple enough that it's seen as fair to apply them after testing on common/popular platforms and fix any side-effects that show up on peculiar or uncommon hosts as they manifest. HEAD is implicitly unstable (except during the stage 3 stabilisation process before a release of course.) cheers, DaveK
Re: GCC primary/secondary platforms?
On 4/8/2010 6:24 PM, Dave Korn wrote: Nor did I see anyone give any changes in configure procedure. Giving it another try at a new download today. Well, nothing has changed, but then again I haven't seen anyone else complaining about this, so there's probably some problem in your build environment; let's see what happens with your fresh build. (I've built the 4.5.0-RC1 candidate without any complications and am running the tests right now.) Built OK this time around, no changes here either, except for cygwin1 update. testsuite results in a couple of days. Thanks. -- Tim Prince
Re: GCC primary/secondary platforms?
> I'm still wondering: Do GCC developers routinely > test their patches on MIPS, ARM, and S390 platforms > (for example)? I signed up for the 'cfarm' and don't see > an S390 there, and some of the secondary targets > look like they might be really SLOW? GCC developers test patches according to the guidelines at: http://gcc.gnu.org/contribute.html Adding a new compiler to the collection is a different thing. We must have some evidences that it will work reasonably well on (at least) primary and secondary platforms, so a good coverage of architecture types is required. -- Eric Botcazou
