Re: Build fail
Ian Lance Taylor wrote : Kai Ruottu <[EMAIL PROTECTED]> writes: Ok, the traditional "evolutionary" method is to not reinvent the wheel with the already tested target components but let then be as they are and produce only the stuff required for the new $host, the GNU binutils and the GCC sources. NOT the target C libraries because they already are there for the existing targets! The Kegel's idealism says that also all these MUST be built with the new GCC. The glibc, the X11 libraries, the Gnome libraries, the KDE libraries, the termcap, the ncurses, Horrible "bolshevism/bullshitism" I would say What in the world are you talking about? Some stupid typos like 'then' instead of 'them', 'sources' appearing after 'GCC', could have caused you to write this, but I don't think it being the case... crosstool is a one stop shop for people who don't want to figure out how everything fits together. Given that, it clearly must build the target libraries. It can't assume that they already exist. This has no typos I think, but despite ot that it sounds like asking that "if the sun is a star, why we don't see it among the other stars at night"? Quite clear question but very hard to answer... So what in the world are you then talking about? That everyone should rebuild the target glibc already having its runtimes already installed on the target system? That those "installed runtimes" really don't exist there? One sees them there but what one sees isn't really true? Everyone can see the sun go around the earth but that isn't the case? When everyone knows how a star looks like and that stars can be seen only at night, the sun cannot be a star when it is so big and it really cannot be seen at night? Maybe I'm stupid when for instance seeing a glibc for Linux/PPC in many Linux distros and I really believe it working as the "target C library" when producing a crosstoolchain for any Linux/PPC :-( For which existing targets the prebuilt C libraries are missing? Or which are the targets which don't have any "suitable", "compatible" or something C library which could serve as that temporary bootstrap "target C library" during the GCC build? In those "special optimized for something" toolchain cases... I'm sorry crosstool doesn't fit your philosophical notions (which are, moreover, incorrect as stated). If you have something substantive to say about crosstool--like, say, it doesn't work, or doesn't do what people want--then say that. Ok, crosstool doesn't work and it doesn't do what the ignorant people think it doing! The cases are many where it has no sanity, but lets take two very common from the "embedded Linux" world for which "crosstool" was made : 1. remote debugging - the libs on the cross-host and the target must be identical 2. Java - for some totally unclear reason mixing a self-made 'libgcj.so' with existing installed C and C++ runtimes doesn't work. Not even in cases where both the installed system and the crosstoolchain have used totally identical sources, the libraries for the cross-host only being prebuilt on some other system than the libraries on the installed system. Generally the case is about producing a crosstoolchain for an existing Linux system, and the goal is to produce apps for this system, not replace it with something totally self-built. And in these cases the replacement of the target libraries with self-built ones is not recommended by me. Others may disagree but I have the right to tell my own
Re: Division by zero
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 10, 2007 at 03:09:41PM +0200, Robert Dewar wrote:
> Ian Lance Taylor wrote:
> > "Jie Zhang" <[EMAIL PROTECTED]> writes:
> >> But now gcc seems to optimize it away. For the following function:
> >>
> >> $ cat t.c
> >> #include
> >> void foo (int rc)
> >> {
> >> int x = rc / INT_MAX;
> >> x = 4 / x;
> >> }
> >
> > I believe we still keep division by zero in general. In your example
> > it gets optimized away because it is dead code. Nothing uses x.
Right. Sometimes it's tricky to remember that NOT reciting Hamlet's
soliloquy also qualifies as "undefined behaviour"! :)
> And it is certainly reasonable to do this optimization given that
> the result of the division is undefined in C.
There's nothing wrong with foo(INT_MAX). Or variants involving INT_MIN.
- --
A PC without Windows is like ice cream without ketchup.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF0DEcwyMv24BBd/gRAqkXAJ90Oi+pgZAWwE9nwu7HIA/AbYF32QCfaurK
bqj67tA92Uqcwj+jfvUrQTQ=
=WBmH
-END PGP SIGNATURE-
Re: gcc-4.3, glibc and AC_PROG_CC_STDC
On Sun, Feb 11, 2007 at 09:51:33PM -0800, Paul Eggert wrote: > > Given that there is still discussion and work on GCC for this topic > > anyway[1], I don't think Autoconf should be doing anything just yet. Yeah, it is just too early. > Both of the solutions that Bruno suggested seem too drastic to me as > well. I hope we can come up with something less intrusive. > > Once GCC 4.3 settles down, perhaps we can work around any remaining > problems with gnulib's wchar module. When GCC implements -fgnu-extern-inline switch (or -fgnu89-extern-inline?), glibc will likely switch to using that switch when building itself and adding gnu_inline attributes to installed headers. > But for this case I'm > inclined to ask, along with Ralf, why GCC 4.3 doesn't apply > fixincludes to the troublesome include files. fixinclude is applied by gcc 4.3, but incorrectly. It edits a few headers by removing extern keyword for __STDC__ >= 199901L from extern inline and for the biggest part it just disables glibc optimizations. The right fix there is to do nothing if __extern_inline macro is already defined (that means the headers are using gnu_inline attribute as appropriate) and otherwise add gnu_inline attribute to all extern inlines. Jakub
Re: GCC 4.1.2 RC2
Mark Mitchell writes: > Kaveh R. GHAZI wrote: > > [Java folks: see below for check-in window for daylight savings time > patches.] > > Therefore, if the Java folks have daylight savings time patches that > they would like to check in, please do so before Monday evening, > California time. Done. Andrew.
Re: Build fail
Kai Ruottu <[EMAIL PROTECTED]> writes: > For which existing targets the prebuilt C libraries are missing? Or > which are the > targets which don't have any "suitable", "compatible" or something C library > which could serve as that temporary bootstrap "target C library" > during the GCC > build? In those "special optimized for something" toolchain cases... The prebuilt C libraries are missing precisely when you are bootstrapping the target. You seem to be jumping from the fact that in some cases crosstool does more than is needed, and in some cases is in fact not what you want, to assuming that crosstool always does too much and is always useless. That makes no sense. Ian
Re: Is compare no longer enabled by default?
On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote: > On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote: > > "make bootstrap" used to compare stage2 and stage3 after gcc was > > bootstrapped. "make bootstrap" would abort if comparison was failed. > > Now, compare stage2 and stage3 is not longer done for > > "make bootstrap". Is that intentional? I think it is a very bad > > idea. > > I opened a bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767 I can't reproduce this. Last night's build of the trunk for me, on i686-pc-linux-gnu, produced a log containing Comparing stages 2 and 3 Comparison successful. This is the output for the trunk and for the 4.2 branch. For the 4.1 branch, we get more verbose output, showing all of the compare commands. HJ, perhaps you were looking for the verbose output and didn't see it?
Re: Is compare no longer enabled by default?
On Mon, Feb 12, 2007 at 09:53:00AM -0800, Joe Buck wrote: > On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote: > > On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote: > > > "make bootstrap" used to compare stage2 and stage3 after gcc was > > > bootstrapped. "make bootstrap" would abort if comparison was failed. > > > Now, compare stage2 and stage3 is not longer done for > > > "make bootstrap". Is that intentional? I think it is a very bad > > > idea. > > > > I opened a bug: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767 > > I can't reproduce this. Last night's build of the trunk for me, on > i686-pc-linux-gnu, produced a log containing > > Comparing stages 2 and 3 > Comparison successful. > > This is the output for the trunk and for the 4.2 branch. For the 4.1 > branch, we get more verbose output, showing all of the compare commands. > HJ, perhaps you were looking for the verbose output and didn't see it? I was comparing against the old output. I have closed the bug. H.J.
Re: GCC 4.1.2 RC2
Ian, Richard, Diego --
I've explicitly forwarded this to you, as folks who have done work on
middle-end optimization and have seen lots of real-world code.
(That's not to say that I'm not looking for comments from anyone and
everyone -- but I'm specifically trying to get at least some feedback,
so I'm picking on some likely candidates. :-))
Do you have any thoughts on the comments quoted below? Does it seem
overly aggressive to you to assume "f" cannot throw in "g", given:
void f() {}
void g() { f(); }
where this code is in a shared library? Of course, with DWARF2 EH, the
cost is mostly in terms of code size; whereas with SJLJ EH it's also
execution time. Is it silly for me to be worrying about this
pessimization in 4.1.2?
Thanks,
>> 2. g++.dg/tree-ssa/nothrow-1.C fails with -fpic/-fPIC.
>
> This appears to be another manifestation of the problem from PR 29487
> (now fixed). Here, the compiler is again making an unreasonably
> conservative assumption that will substantially penalize C++ shared
> libraries: namely, that all global functions in shared libraries may be
> replaced at link time, and that callers must therefore assume that they
> may throw exceptions.
>
> You are correct that this stems from Richard's patch, though that patch
> made sense on its own: he used the same rules for exceptions that were
> otherwise used for const/pure functions.
>
> I think the key flaw here is that we are using binds_local_p in two
> different ways. One way is to tell us what kind of references we can
> emit; for a locally bound entity we may/must use certain relocations,
> etc., that we cannot with a global entity. However, I think it's
> unreasonably pessimistic to say that just because the user might use the
> linker to replace a function in some way, we can't reason from the
> function's behavior. If the user doesn't state that intent explicitly
> (by declaring the function weak), I think we should be free to optimize
> based on the body of the function.
>
> I think that this suggests that even the definition of
> DECL_REPLACEABLE_P that I checked in is too conservative. Perhaps the
> definition should simply be "DECL_WEAK (decl) && !DECL_COMDAT (decl))";
> in other words, only explicitly weak functions are replaceable from an
> optimization point of view. It was weak functions that were the
> motivation for the original change.
>
> I would certainly appreciate comments from others about this issue.
>
> I do think this is an important issue; it would be bad for Mozilla, KDE,
> etc., to suffer a significant optimization issue in going from 4.1.1 to
> 4.1.2. I was pretty determined to get 4.1.2 out the door, and I really
> don't want to have any functional changes between the last RC and the
> actual release. So, I feel that I have no choice but to do a 4.1.2 RC3
> with a more conservative version of DECL_REPLACEABLE_P.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
[Autovect]dependencies of virtual defs/uses
Hi, I am reading the code of autovect branch and curious about how to deal with the dependencies of virtual defs/uses. In the function vect_analyze_scalar_cycles( ), I found the statement "Skip virtual phi's. The data dependences that are associated with virtual defs/uses ( i.e., memory accesses) are analyzed elsewhere." But where is the code? I tried to search for "vect_induction_def" and "vect_reduction_def" and found that they are not used to assign elsewhere. Is the analysis not implemented yet? Thanks in advance! Jiahua
Re: [Autovect]dependencies of virtual defs/uses
On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote: Hi, I am reading the code of autovect branch and curious about how to deal with the dependencies of virtual defs/uses. In the function vect_analyze_scalar_cycles( ), I found the statement "Skip virtual phi's. The data dependences that are associated with virtual defs/uses ( i.e., memory accesses) are analyzed elsewhere." But where is the code? I tried to search for "vect_induction_def" and "vect_reduction_def" and found that they are not used to assign elsewhere. Is the analysis not implemented yet? Thanks in advance! They show up as data references because of tree-data-reference.c marking them. At lets, that's how other linear loop transforms handles it. Not sure about how vectorizer deals with it specifically Jiahua
Re: [Autovect]dependencies of virtual defs/uses
Thanks! In fact, I should ask how to deal with idiom (such as reduction, induction) recognition for virtual defs/uses. Jiahua 2007/2/12, Daniel Berlin <[EMAIL PROTECTED]>: On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote: > Hi, > > I am reading the code of autovect branch and curious about how to deal > with the dependencies of virtual defs/uses. In the function > vect_analyze_scalar_cycles( ), I found the statement "Skip virtual > phi's. The data dependences that are associated with virtual defs/uses > ( i.e., memory accesses) are analyzed elsewhere." But where is the > code? I tried to search for "vect_induction_def" and > "vect_reduction_def" and found that they are not used to assign > elsewhere. Is the analysis not implemented yet? Thanks in advance! They show up as data references because of tree-data-reference.c marking them. At lets, that's how other linear loop transforms handles it. Not sure about how vectorizer deals with it specifically > > Jiahua >
Re: [Autovect]dependencies of virtual defs/uses
> On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I am reading the code of autovect branch and curious about how to deal > > with the dependencies of virtual defs/uses. In the function > > vect_analyze_scalar_cycles( ), I found the statement "Skip virtual > > phi's. The data dependences that are associated with virtual defs/uses > > ( i.e., memory accesses) are analyzed elsewhere." But where is the > > code? I tried to search for "vect_induction_def" and > > "vect_reduction_def" and found that they are not used to assign > > elsewhere. Is the analysis not implemented yet? Thanks in advance! > > They show up as data references because of tree-data-reference.c marking them. > At lets, that's how other linear loop transforms handles it. > Not sure about how vectorizer deals with it specifically > We don't analyze the def-use cycles created by virtual defs/uses. We make sure that any stmt in the loop that has virtual defs/uses associated with it is a load/store stmt (i.e. has a dataref in its rhs/lhs), and then, separately, we make sure we can analyze all the datarefs in the loop and compute the dependence relations between them. dorit > > > > Jiahua > >
Re: [Autovect]dependencies of virtual defs/uses
> Thanks! In fact, I should ask how to deal with idiom (such as > reduction, induction) recognition for virtual defs/uses. > Just curious - what is this for? (are you interested in this in the context of vectorization? is there a specific example you have in mind?) dorit > Jiahua > > > 2007/2/12, Daniel Berlin <[EMAIL PROTECTED]>: > > On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I am reading the code of autovect branch and curious about how to deal > > > with the dependencies of virtual defs/uses. In the function > > > vect_analyze_scalar_cycles( ), I found the statement "Skip virtual > > > phi's. The data dependences that are associated with virtual defs/uses > > > ( i.e., memory accesses) are analyzed elsewhere." But where is the > > > code? I tried to search for "vect_induction_def" and > > > "vect_reduction_def" and found that they are not used to assign > > > elsewhere. Is the analysis not implemented yet? Thanks in advance! > > > > They show up as data references because of tree-data-reference.c > marking them. > > At lets, that's how other linear loop transforms handles it. > > Not sure about how vectorizer deals with it specifically > > > > > > > > Jiahua > > > > >
Some thoughts and quetsions about the data flow infrastracture
On Sunday I had accidentally chat about the df infrastructure on IIRC. I've got some thoughts which I'd like to share. I like df infrastructure code from the day one for its clearness. Unfortunately users don't see it and probably don't care about it. With my point of view the df infrastructure has a design flaw. It extracts a lot of information about RTL and keep it on the side. It does not make the code fast. It would be ok if we got a better code quality. Danny told me that they have 1.5% better code using df. It is a really big improvement (about half year work for all compiler team according to Proebsting's law). IMHO, it could justify promised 5% compiler slowness. I've checked the branch with last merge point revision 121802 (done Feb 10) on SPECINT2000 on 2.66 Core2 Duo (-mtune=generic -O2 were used) and found that there is no improvement but degradation about 0.5% (1888 for the branch vs 1896 for mainline on the branch point. it is without twolf which is broken for now). The code size is also about 0.45% bigger on the branch. Getting 0.5% and 11.5% slowness (308sec vs 275sec for compiling SPECINT2000) does not seems reasonable especially if we have no alternative faster path (even if the old live analysis is the mess). Someone could object me that this infrastructure makes new optimization implementation easier. But I've heard opinion that rtl optimizations should be moved to SSA and should be only few optimizations on RTL as code selection, the insn scheduling and RA. Even rewriting the current optimizations on the new data flow infrastructure makes situation worse because it will be not easy to rid off the data flow infrastructure because probably part of the flaw in the df interface. So it might create problems in the future. Especially I did not like David Edelhson's phrase "and no new private dataflow schemes will be allowed in gcc passes". It was not such his first expression. Such phrases are killing competition which is bad for gcc. What if the new specialized scheme is faster. What if somebody decides to write another better df infrastructure from the scratch to solve the coming df infrastructure problems. So could be somebody from steering committee be kind and answer me Is it (prohibiting to use other dataflow schemes) steering committee decision? If it so, should steering committee do such technical decision? Some people on steering committee are not experts in gcc compiler, some of them are not experts in this part of the compiler. I am not in opposition to merge if it satisfies the merge criteria. People've done a lot of work. It is too late. I've should oppose the criteria when they were discussed. Sorry I've missed the discussion if there were such discussion. I am just rising some questions and saying that more work will be needed for df-infrastructure even after the merge. Vlad
Re: GCC 4.1.2 RC2
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
> Does it seem overly aggressive to you to assume "f" cannot throw
> in "g", given:
>
> void f() {}
> void g() { f(); }
>
> where this code is in a shared library?
Yes.
If F is part of the exported (and overridable) interface of
the shared library, one should be able to replace it with
any valid function.
If the shared library needs F to not be able to throw, then
one can just as easily define the function interface to be
void f() throw();
If F was mistakenly placed in the overridable interface of
the shared library, then the fix is elsewhere.
r~
Re: Some thoughts and quetsions about the data flow infrastracture
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: I like df infrastructure code from the day one for its clearness. Unfortunately users don't see it and probably don't care about it. With my point of view the df infrastructure has a design flaw. It extracts a lot of information about RTL and keep it on the side. It does not make the code fast. It also does not make code slow. And the data it extracts and keeps on the side, could be used to simplify many algorithms in gcc (most notably, cprop, mode switching, and regmove). There is a tremendous potential for speedups in RTL passes if they start using the df register caches, instead of traversing the PATTERN of every insn. Gr. Steven
Re: [Autovect]dependencies of virtual defs/uses
Oh, I see. For reduction and induction, you don't need to deal with the condition with vdef. I am considering how to implement an idiom with vdef, like SCAN (prefix sum). And by the way, do you support idioms with vuses? Jiahua 2007/2/12, Dorit Nuzman <[EMAIL PROTECTED]>: > Thanks! In fact, I should ask how to deal with idiom (such as > reduction, induction) recognition for virtual defs/uses. > Just curious - what is this for? (are you interested in this in the context of vectorization? is there a specific example you have in mind?) dorit > Jiahua > > > 2007/2/12, Daniel Berlin <[EMAIL PROTECTED]>: > > On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I am reading the code of autovect branch and curious about how to deal > > > with the dependencies of virtual defs/uses. In the function > > > vect_analyze_scalar_cycles( ), I found the statement "Skip virtual > > > phi's. The data dependences that are associated with virtual defs/uses > > > ( i.e., memory accesses) are analyzed elsewhere." But where is the > > > code? I tried to search for "vect_induction_def" and > > > "vect_reduction_def" and found that they are not used to assign > > > elsewhere. Is the analysis not implemented yet? Thanks in advance! > > > > They show up as data references because of tree-data-reference.c > marking them. > > At lets, that's how other linear loop transforms handles it. > > Not sure about how vectorizer deals with it specifically > > > > > > > > Jiahua > > > > >
Re: GCC 4.1.2 RC2
Richard Henderson wrote:
> On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
>> Does it seem overly aggressive to you to assume "f" cannot throw
>> in "g", given:
>>
>> void f() {}
>> void g() { f(); }
>>
>> where this code is in a shared library?
>
> Yes.
>
> If F is part of the exported (and overridable) interface of
> the shared library, one should be able to replace it with
> any valid function.
I understand that people do this for C code (e.g., replace memcpy, or
other bits of the C library). Those routines aren't generally
manipulating global data; they're often stand-alone APIs that just
happened to be grouped together into a single library.
But, aren't big C++ shared libraries rather different? Does KDE
actually use throw() everywhere, or visibility attributes? But,
presumably, most people don't replace the implementation of
ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here,
but I'd be surprised if there aren't large amounts of legacy code that
would be hurt by this change. Do you disagree?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Some thoughts and quetsions about the data flow infrastracture
Vladimir Makarov wrote: > On Sunday I had accidentally chat about the df infrastructure on > IIRC. I've got some thoughts which I'd like to share. > > I like df infrastructure code from the day one for its clearness. > Unfortunately users don't see it and probably don't care about it. You're right that users don't care what the guts of the compiler look like. That's exactly right: they care only about about the speed of the compiler, the speed of the generated code, correctness of the generated code, overall quality, etc. However, my understanding (as someone who's not an expert on the DF code base) is that, as you say, the new stuff is much tidier. I understood the objective to be not so much that DF itself would directly improve the generated code, but rather than it would provide much-need infrastructure that would allow future improvements. This is a lot like TREE-SSA which, by itself, wasn't so much about optimization as it was about providing a platform for optimization. Obviously, making sure that the DF code isn't actively hurting us when it goes into the compiler is part of the agreed-upon criteria. But, I don't think it needs to markedly help at this point, as long as people are comfortable with the interfaces and functionality it provides. > So could be somebody from steering committee be kind and answer me > >Is it (prohibiting to use other dataflow schemes) steering committee > decision? No, the Steering Committee has not considered this issue. As you suggest, I don't think it's something the SC would want to consider; it's a technical issue. I'd certainly think that it would be good for all passes to use the DF infrastructure. However, if there were really some special case where we could do markedly better without it, and no feasible way to give the special-case information to the core DF code, then I'm sure everyone would agree that it made sense to use something different. But, that would be only in extraordinary situations, rather than having lots of reinvention of the same infrastructure. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: how to dump tree in pt.c:tsubst?
Larry Evans wrote: How does one dump the trees in pt.c:tsubst in some hunan readable cp_dump_tree(&di, args); cp_dump_tree is a hook for printing C++ specific trees. Try dump_node in tree-dump.c instead. Or one of the other functions in this file. I'm not sure if you can call dump_node directly. There are also functions in print-tree.c which produce a different style of output. The entry point here is debug_tree. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: GCC 4.1.2 RC2
Mark Mitchell <[EMAIL PROTECTED]> writes: > But, aren't big C++ shared libraries rather different? Does KDE > actually use throw() everywhere, or visibility attributes? But, > presumably, most people don't replace the implementation of > ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, > but I'd be surprised if there aren't large amounts of legacy code that > would be hurt by this change. Do you disagree? I don't really have any doubt that somebody, somewhere, wants to override a function in a C++ shared library, and wants the overriding function to throw an exception. There is really only one correct compiler behaviour here. But if gcc 4.1.1 behaved one way with regard to overriding a function with a function that throws an exception, I think we can probably get away with having gcc 4.1.2 behave the same way. It should ideally be recorded as a known issue somewhere, though. Ian
Re: meaning of --enable-checking flags
On 02/11/2007 05:59 PM, Gerald Pfeifer wrote: On Sun, 11 Feb 2007, Larry Evans wrote: [snip] I can't comment on the contents, but that HTML file is generated from our texinfo documentation; the master source for that is gcc/doc/install.texi in our SVN repository. Gerald THanks Gerald. Checked out svn today and made the change shown by the attached output of the svn diff command. Does this look OK? cd ~/download/gcc/svn/trunk/gcc/doc/ svn diff install.texi Index: install.texi === --- install.texi(revision 121856) +++ install.texi(working copy) @@ -1229,6 +1229,10 @@ increase the risk of undetected internal errors causing wrong code to be generated. +For a brief explanation of the flags, see the comments in +gcc/config.in. For example, to find an explanation of flag, gcac, +search for ENABLE_GC_ALWAYS_COLLECT. + @item --enable-coverage @itemx [EMAIL PROTECTED] With this option, the compiler is built to collect self coverage Compilation finished at Mon Feb 12 15:13:32
Re: Some thoughts and quetsions about the data flow infrastracture
> Vladimir Makarov writes: Vlad> Especially I did not like David Edelhson's phrase "and no new Vlad> private dataflow schemes will be allowed in gcc passes". It was not Vlad> such his first expression. Such phrases are killing competition which Vlad> is bad for gcc. What if the new specialized scheme is faster. What Vlad> if somebody decides to write another better df infrastructure from the Vlad> scratch to solve the coming df infrastructure problems. First, "another better df infrastructure" is not a private dataflow scheme. If someone else wants to rewrite it from scratch and do a better job, be my guest. Most commercial compilers rewrite their infrastructure every 5 to 10 years; GCC accretes kludges. The other commercial compilers learn from their algorithms and previous design to implement a new, maintainable infrastructure that meets the needs of all algorithms. Second, this has nothing to do with competition. As I and others explained on the IRC chat, the new df is general infrastructure. If you can speed it up more, that's great. If you need another dataflow problem solved, add it to the infrastructure. GCC is not served well by five (5) different dataflow solvers, each with its own quirks, bugs, duplicative memory and duplicative maintenance. It would be a waste to improve GCC's infrastructure and then have the hard work undermined by recreating the duplication without good justification. Third, I am disappointed that you chose to make this argument personal. David
Re: GCC 4.1.2 RC2
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > > But, aren't big C++ shared libraries rather different? Does KDE > > actually use throw() everywhere, or visibility attributes? But, > > presumably, most people don't replace the implementation of > > ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, > > but I'd be surprised if there aren't large amounts of legacy code that > > would be hurt by this change. Do you disagree? > > I don't really have any doubt that somebody, somewhere, wants to > override a function in a C++ shared library, and wants the overriding > function to throw an exception. There is really only one correct > compiler behaviour here. I strongly agree that there is only one correct behaviour here. If KDE doesn't use throw(), or visibility attributees, that's a failing in KDE, not the compiler. r~
Re: Some thoughts and quetsions about the data flow infrastracture
David Edelsohn wrote: Vladimir Makarov writes: Third, I am disappointed that you chose to make this argument personal. David, I really apologize to make it personal. We are all one community and we are all thinking to make gcc a better compiler.
Re: GCC 4.1.2 RC2
On Mon, Feb 12, 2007 at 01:30:41PM -0800, Richard Henderson wrote: > On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: > > Mark Mitchell <[EMAIL PROTECTED]> writes: > > > > > But, aren't big C++ shared libraries rather different? Does KDE > > > actually use throw() everywhere, or visibility attributes? But, > > > presumably, most people don't replace the implementation of > > > ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, > > > but I'd be surprised if there aren't large amounts of legacy code that > > > would be hurt by this change. Do you disagree? > > > > I don't really have any doubt that somebody, somewhere, wants to > > override a function in a C++ shared library, and wants the overriding > > function to throw an exception. There is really only one correct > > compiler behaviour here. > > I strongly agree that there is only one correct behaviour here. > > If KDE doesn't use throw(), or visibility attributees, that's a > failing in KDE, not the compiler. Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings? If so, then it might be better to push the fix that allows overrides that throw back to 4.2, and circulate warnings to affected projects that they will want to use throw() and attributes more, giving them until 4.2 to fix any issues found.
Re: GCC 4.1.2 RC2
Richard Henderson wrote: > On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: >> Mark Mitchell <[EMAIL PROTECTED]> writes: >> >>> But, aren't big C++ shared libraries rather different? Does KDE >>> actually use throw() everywhere, or visibility attributes? But, >>> presumably, most people don't replace the implementation of >>> ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, >>> but I'd be surprised if there aren't large amounts of legacy code that >>> would be hurt by this change. Do you disagree? >> I don't really have any doubt that somebody, somewhere, wants to >> override a function in a C++ shared library, and wants the overriding >> function to throw an exception. There is really only one correct >> compiler behaviour here. > > I strongly agree that there is only one correct behaviour here. If you both feel that way, it's good enough for me. As a long-time C++ programmer, I'd sure be surprised to find that my code was optimized substantially differently -- in this kind of high-level way, not just at the lower levels of addressing modes and such -- just because I added "-fpic" to the command-line, but so be it. In that case, I'll not make any further changes in this area. I can't really guarantee that any change I would make to 4.1.2 would restore exactly identical behavior to the 4.1.1 release without backing out other larges bits of infrastructure. And, since we think this is the behavior we want going forward, I think we may as well just go with it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.2 RC2
Joe Buck wrote: >> If KDE doesn't use throw(), or visibility attributees, that's a >> failing in KDE, not the compiler. > > Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings? Yes. On workstation and server systems, most of the issue will be somewhat larger binaries. On embedded systems, code space is more precious, so there might be more impact. The impact will be greatest on SJLJ systems with shared libraries if such things exist. However, there are as far as I know, zero reports of this as an actual problem in practice. Any impact is likely to vary greatly from library to library. And, many users concerned about code size are going to have turned off EH altogether. So, I don't think we should further hold things up. > If so, then it might be better to push the fix that allows overrides that > throw back to 4.2, and circulate warnings to affected projects that they > will want to use throw() and attributes more, giving them until 4.2 to fix > any issues found. I don't think that's very practical. We'd have to back out some of the other changes that were made since 4.1.1, and in so doing we'd lose bug fixes for (other) correctness issues. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.2 RC2
Joe Buck wrote: > > Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings? On Mon, Feb 12, 2007 at 01:53:10PM -0800, Mark Mitchell wrote: > Yes > > If so, then it might be better to push the fix that allows overrides that > > throw back to 4.2, and circulate warnings to affected projects that they > > will want to use throw() and attributes more, giving them until 4.2 to fix > > any issues found. > I don't think that's very practical. We'd have to back out some of the > other changes that were made since 4.1.1, and in so doing we'd lose bug > fixes for (other) correctness issues. OK, I withdraw the suggestion. It's worth mentioning in release notes though.
gcc-4.1-20070212 is now available
Snapshot gcc-4.1-20070212 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070212/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 121864 You'll find: gcc-4.1-20070212.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070212.tar.bz2 C front end and core compiler gcc-ada-4.1-20070212.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070212.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070212.tar.bz2 C++ front end and runtime gcc-java-4.1-20070212.tar.bz2 Java front end and runtime gcc-objc-4.1-20070212.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070212.tar.bz2The GCC testsuite Diffs from 4.1-20070205 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
GCC 4.1.2 RC3 Cancelled
Given that we're not going to mess about further with DECL_REPLACEABLE_P (since the case that Kaven raised involving PIC compilation of functions using exceptions is a non-bug), I don't think we need to do RC3. The only changes that we've had since RC2 are Andrew Haley's Java timezone changes and Joseph's update of translation files. If the build change for non-standard shells is also checked in tonight that's fine; if not, there's a good workaround. So, my current intent is build the final 4.1.2 release tomorrow evening in California. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Some thoughts and quetsions about the data flow infrastracture
> > Vladimir Makarov writes: > > Vlad> Especially I did not like David Edelhson's phrase "and no new > Vlad> private dataflow schemes will be allowed in gcc passes". It was not > Vlad> such his first expression. Such phrases are killing competition which > Vlad> is bad for gcc. What if the new specialized scheme is faster. What > Vlad> if somebody decides to write another better df infrastructure from the > Vlad> scratch to solve the coming df infrastructure problems. > > First, "another better df infrastructure" is not a private > explained on the IRC chat, the new df is general infrastructure. If you > can speed it up more, that's great. If you need another dataflow problem > solved, add it to the infrastructure. GCC is not served well by five (5) > different dataflow solvers, each with its own quirks, bugs, duplicative > memory and duplicative maintenance. I agree. "Competition" and making things "better" is not always the right approach for a project the size of GCC: in fact, it's more often *not* the right approach. In a project like GCC, stability is more important. Once something is written, it's obsolete. But changing something in the infrastructure (or duplicating it) affects stability and the gain is rarely worth it.
re: Some thoughts and quetsions about the data flow infrastructure
> On Sunday I had accidentally chat about the df infrastructure on > IIRC. I've got some thoughts which I'd like to share. > > I like df infrastructure code from the day one for its clearness. > Unfortunately users don't see it and probably don't care about it. > With my point of view the df infrastructure has a design flaw. It > extracts a lot of information about RTL and keep it on the side. It > does not make the code fast. It would be ok if we got a better code > quality. Danny told me that they have 1.5% better code using df. It > is a really big improvement (about half year work for all compiler > team according to Proebsting's law). IMHO, it could justify promised > 5% compiler slowness. > Vlad, I think that different people can have different perspectives. You have been working on improving the register allocation for several years, but very little has come of it because the reload infrastructure does not suit itself to being integrated with modern register allocators. You have spent several years of work without touching the underlying problem that reload is generally going to defeat almost any effort to get good benefits out of a new register allocator. I do not want to denigrate your work in any way, but at the end of the day, any new register allocator will be compromised by the existing reload implementation. I am interested bringing the rest of the back end into the modern world. While some of the passes can and should be moved into the ssa middle end of the compiler, there are several optimizations that can only be done after the details of the target have been fully exposed. My experience with trying to do this was that the number one problem was that the existing dataflow is in many cases wrong or too conservative and that it was not flexible enough to accommodate many most modern optimization techniques. So rather than hack around the problem, I decided to attack the bad infrastructure problem first, and open the way for myself and the others who work on the back end to benefit from that infrastructure to get the rest of passes into shape. There are certainly performance issues here. There are limits on how much I, and the others who have worked on this have been able to change before we do our merge. So far, only those passes that were directly hacked into flow, such as dce, and auto-inc-dec detection have been rewritten from the ground up to fully utilize the new framework. However, it had gotten to the point where the two frameworks really should not coexist. Both implementations expect to work in an environment where the information is maintained from pass to pass and doing with two systems was not workable. So the plan accepted by the steering committee accommodates the wholesale replacement of the dataflow analysis but even after the merge, there will still be many passes that will be changed. I would have liked to have the df information more tightly integrated into the rtl rather than it being on the side. It is cumbersome to keep this information up to date. However, the number of places in the backends that depend on the existing rtl data structures apis make such a replacement very difficult. I do believe that by the time that we merge the branch, we will be down to a 5% compile time regression. While I would like this number to be 0% or negative, I personally believe that having precise and correct information is worth it and that over time we will be able to remove that 5% penalty. As far as the other regressions, these will be dealt with very soon. Kenny
Re: Some thoughts and quetsions about the data flow infrastructure
Vlad, I think that different people can have different perspectives. You have been working on improving the register allocation for several years, but very little has come of it because the reload infrastructure does not suit itself to being integrated with modern register allocators. You have spent several years of work without touching the underlying problem that reload is generally going to defeat almost any effort to get good benefits out of a new register allocator. I do not want to denigrate your work in any way, but at the end of the day, any new register allocator will be compromised by the existing reload implementation. Ken, to be exact I've been working for a bit more 2 years on the register allocator itself. Probably you don't know I attacked exactly underlying problem - the reload. If you look at YARA branch, it is register allocator without the reload. And I am really worring that there is a little outcome. But ridding the reload off is so complex problem. I can not work on it for a few more years. I need some result too. Using the experience I've got from YARA branch I've created another register allocator (IRA branch) to make it ready for gcc-4.4. IRA still uses reload. But may be I have higher standards. I don't want to include the code in sake of inclusion. I have no worse code generated by IRA than the current register allocator. The code size is smaller for the most platforms. For some platforms I have better generated code (up to 4% on SPECINT2000 in 32-bt mode: bo exact 1930 vs 1850 for Core2 according this weekend benchmarking). Actually I could make IRA ready for gcc4.3. It works for x86, x86_64, itanium, ppc, sparc, s390, arm. It is optional so other platform can use the current register allocator. But I don't to rush. But still you are right the reload comprising the generated code. If you are interesting in my opinion, df infrastracture is a tiny part of RA implementation problem (and as I understand insn scheduler and code selection). Actually IRA uses he tDF infrastracture but it can be easily to be switched to the old life anaysis. I am interested bringing the rest of the back end into the modern world. While some of the passes can and should be moved into the ssa middle end of the compiler, there are several optimizations that can only be done after the details of the target have been fully exposed. Bring the rest of the back end into the modern word is too chalenging task. If you really want it, imho you should attack RTL and machine descriptions. But this task is a magnitude more difficult than introducing tree-SSA. My experience with trying to do this was that the number one problem was that the existing dataflow is in many cases wrong or too conservative and that it was not flexible enough to accommodate many most modern optimization techniques. So rather than hack around the problem, I decided to attack the bad infrastructure problem first, and open the way for myself and the others who work on the back end to benefit from that infrastructure to get the rest of passes into shape. I am not against a new DF infrastracture, more accurate one. I am against a slower infrastracture. There are certainly performance issues here. There are limits on how much I, and the others who have worked on this have been able to change before we do our merge. So far, only those passes that were directly hacked into flow, such as dce, and auto-inc-dec detection have been rewritten from the ground up to fully utilize the new framework. However, it had gotten to the point where the two frameworks really should not coexist. Both implementations expect to work in an environment where the information is maintained from pass to pass and doing with two systems was not workable. So the plan accepted by the steering committee accommodates the wholesale replacement of the dataflow analysis but even after the merge, there will still be many passes that will be changed. Does it means that compiler will be even more slower? I would have liked to have the df information more tightly integrated into the rtl rather than it being on the side. It is cumbersome to keep this information up to date. However, the number of places in the backends that depend on the existing rtl data structures apis make such a replacement very difficult. I do believe that by the time that we merge the branch, we will be down to a 5% compile time regression. While I would like this number to be 0% or negative, I personally believe that having precise and correct information is worth it and that over time we will be able to remove that 5% penalty. As far as the other regressions, these will be dealt with very soon. Great!
Re: Pre Compiled Headers
On Feb 11, 2007, at 1:17 PM, Brendon Costa wrote: I am coding an extension for GCC and am having some difficulty with pre-compiled headers. I dont know if my understanding of how they work is completely correct and so my code is getting a segfault. You _must_ have clean data structures and complete type safety. You cannot have any pointers to GCed memory any place but GCed memory, or file data marked with GTY(()) markers. The last rule is a good approximation, cpp for examples deviates from this general rule. So i also hook into c_common_no_more_pch() Ick. You seem to have thought too much about pch. Instead, pretend it isn't there, except for doing the GTY(()) thing on all static scope data. c_common_no_more_pch seems like the wrong place. You calculate things when you have the data to calculate from and someplace to put it, but the code there. You want to do it at the end of file processing, put it there. You want to do it from the parser, or optimizer, put it there. 1) Is there a better place to hook into to know when the PCH engine has completed reconstructing the tree nodes? See why this is the wrong question? The question is, I am doing this calculation, where should I put it? The answer to that is, when you have all the data from which you need to do the calculation and a place to store it. 2) Is there something wrong in the way i understand the reconstruction of data by the PCH engine? I assumed it would re- construct a full tree hierarchy if i rooted a tree node. Yes. The mental model you should use for PCH is this, when processing a header, the compiler does a complete memory walk and dumps it to a file. Upon `reading' the pch file, it mmaps all that memory back in, throwing out all previously allocated memory, and continues just after the #include. If you have any code that knows about pch (other than GTY(())), you're probably trying to be too smart about pchness. I can't tell if you are or not, unless you tell me why you want to be.
Re: Some thoughts and quetsions about the data flow infrastracture
Richard Kenner wrote: Vladimir Makarov writes: Vlad> Especially I did not like David Edelhson's phrase "and no new Vlad> private dataflow schemes will be allowed in gcc passes". It was not Vlad> such his first expression. Such phrases are killing competition which Vlad> is bad for gcc. What if the new specialized scheme is faster. What Vlad> if somebody decides to write another better df infrastructure from the Vlad> scratch to solve the coming df infrastructure problems. First, "another better df infrastructure" is not a private explained on the IRC chat, the new df is general infrastructure. If you can speed it up more, that's great. If you need another dataflow problem solved, add it to the infrastructure. GCC is not served well by five (5) different dataflow solvers, each with its own quirks, bugs, duplicative memory and duplicative maintenance. I agree. "Competition" and making things "better" is not always the right approach for a project the size of GCC: in fact, it's more often *not* the right approach. In a project like GCC, stability is more important. Once something is written, it's obsolete. But changing something in the infrastructure (or duplicating it) affects stability and the gain is rarely worth it. In general, I am agree with this. I am just opposing to the strong words "not allowed". I think it should be decided in each concrete case.
Re: [Autovect]dependencies of virtual defs/uses
On Feb 12, 2007, at 12:54 PM, Jiahua He wrote: Oh, I see. For reduction and induction, you don't need to deal with the condition with vdef. I am considering how to implement an idiom with vdef, like SCAN (prefix sum). And by the way, do you support idioms with vuses? Jiahua 2007/2/12, Dorit Nuzman <[EMAIL PROTECTED]>: > Thanks! In fact, I should ask how to deal with idiom (such as Please don't top post, thanks.
Re: Some thoughts and quetsions about the data flow infrastracture
Steven Bosscher wrote: On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: I like df infrastructure code from the day one for its clearness. Unfortunately users don't see it and probably don't care about it. With my point of view the df infrastructure has a design flaw. It extracts a lot of information about RTL and keep it on the side. It does not make the code fast. It also does not make code slow. And the data it extracts and keeps on the side, could be used to simplify many algorithms in gcc (most notably, cprop, mode switching, and regmove). There is a tremendous potential for speedups in RTL passes if they start using the df register caches, instead of traversing the PATTERN of every insn. In some passes RTL is scanned once. For example, insn scheduler now does it once to build the data dependency. In this case the df scans RTL once + writes and reads the df structures and always loosing in the speed. I know some work is being done on incremental df analysis. It could decrease time for rescanning RTL between passes. Let us hope on this.
Re: Some thoughts and quetsions about the data flow infrastracture
Mark Mitchell wrote: Vladimir Makarov wrote: On Sunday I had accidentally chat about the df infrastructure on IIRC. I've got some thoughts which I'd like to share. I like df infrastructure code from the day one for its clearness. Unfortunately users don't see it and probably don't care about it. You're right that users don't care what the guts of the compiler look like. That's exactly right: they care only about about the speed of the compiler, the speed of the generated code, correctness of the generated code, overall quality, etc. However, my understanding (as someone who's not an expert on the DF code base) is that, as you say, the new stuff is much tidier. I understood the objective to be not so much that DF itself would directly improve the generated code, but rather than it would provide much-need infrastructure that would allow future improvements. This is a lot like TREE-SSA which, by itself, wasn't so much about optimization as it was about providing a platform for optimization. Imho, it is not a right analogy. The right analogy would be a new RTL (low-level IR). I know insn scheduler and RA well and I would not exaggerrate the DF importance such way at least for these tasks. Obviously, making sure that the DF code isn't actively hurting us when it goes into the compiler is part of the agreed-upon criteria. But, I don't think it needs to markedly help at this point, as long as people are comfortable with the interfaces and functionality it provides. So could be somebody from steering committee be kind and answer me Is it (prohibiting to use other dataflow schemes) steering committee decision? No, the Steering Committee has not considered this issue. As you suggest, I don't think it's something the SC would want to consider; it's a technical issue. I'd certainly think that it would be good for all passes to use the DF infrastructure. However, if there were really some special case where we could do markedly better without it, and no feasible way to give the special-case information to the core DF code, then I'm sure everyone would agree that it made sense to use something different. But, that would be only in extraordinary situations, rather than having lots of reinvention of the same infrastructure. Thanks for the clarification, Mark.
Re: Some thoughts and quetsions about the data flow infrastracture
Vladimir N. Makarov wrote: >> However, my understanding (as someone who's not an expert on the DF code >> base) is that, as you say, the new stuff is much tidier. I understood >> the objective to be not so much that DF itself would directly improve >> the generated code, but rather than it would provide much-need >> infrastructure that would allow future improvements. This is a lot like >> TREE-SSA which, by itself, wasn't so much about optimization as it was >> about providing a platform for optimization. > Imho, it is not a right analogy. The right analogy would be a new RTL > (low-level IR). I know insn scheduler and RA well and I would not > exaggerrate the DF importance such way at least for these tasks. I was not trying to suggest that DF is necessarily as sweeping a change as TREE-SSA. Certainly, it's not a completely change to the representation. The sense in which I meant to suggest similarity is that DF is infrastructure. It's not that DF is a new optimization; it's that it's a facilitator of optimizations. The point is to get more accurate information to the various RTL passes, in a more consistent way, so that they can do their jobs better. And, to be able to adjust those patches to use newer, better algorithms, which depend on easy access to dataflow information. And, perhaps, to permit the creation of new optimization passes that will only be useful because more accurate information is available. My point is that I don't think that the right criteria for DF is whether it makes the generated code faster. So long as it doesn't make the generated code slower, and so long as the APIs seem well designed, and so long as it doesn't make the compiler itself too much slower, I think it's a win. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Some thoughts and quetsions about the data flow infrastracture
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: On Sunday I had accidentally chat about the df infrastructure on IIRC. I've got some thoughts which I'd like to share. I like df infrastructure code from the day one for its clearness. Unfortunately users don't see it and probably don't care about it. With my point of view the df infrastructure has a design flaw. It extracts a lot of information about RTL and keep it on the side. It does not make the code fast. It would be ok if we got a better code quality. Danny told me that they have 1.5% better code using df. I also said we hadn't run numbers in about a year and a half, because it wasnt our main goal anymore. ... especially if we have no alternative faster path (even if the old live analysis is the mess). I also pointed out that df's merge criteria are no more than 5% compile time degradation. So what are you worried about here? Life analysis isn't just a mess, it's inaccurate, and intertwined with dead store elimination and dead code elimination. Even rewriting the current optimizations on the new data flow infrastructure makes situation worse because it will be not easy to rid off the data flow infrastructure because probably part of the flaw in the df interface. What? The flaw we have now is that every pass creates it's own datastructures and dataflow, and is complete impossible to make dataflow faster without rewriting every single pass. With DF, you could make every single pass faster simply by improving ... DF! If the datastructures it has don't work well enough for any pass of course, you can add your own as df problems and results. So it might create problems in the future. Especially I did not like David Edelhson's phrase "and no new private dataflow schemes will be allowed in gcc passes". It was not such his first expression. Such phrases are killing competition which is bad for gcc. What if the new specialized scheme is faster. What if somebody decides to write another better df infrastructure from the scratch to solve the coming df infrastructure problems. If you want to rewrite DF, please do. But honesty, GCC has enough separate solvers that simply are not faster anymore than df branch's solver. We know. We replaced a lot of them. And that's the thing. We had to go and replace every single one of these, when if they had just used df's solver in the first place (and taken the 1-2% slowdown they probably faced), they would all just have been sped up. Worse, some of these solvers were buggy or inaccurate, so now that we give it better information, faster, we have to go fix bugs that never would have existed had they reused the infrastructure we provided. This is in fact, a lot of what has taken up df branch time. Fixing bugs that fixing the dataflow exposed. I am not in opposition to merge if it satisfies the merge criteria. People've done a lot of work. It is too late. I've should oppose the criteria when they were discussed. Sorry I've missed the discussion if there were such discussion. I am just rising some questions and saying that more work will be needed for df-infrastructure even after the merge. There is always more work to be done. BTW, I'll happily remove DF when all that is left of RTL is the scheduler, RA, and instruction selector. Hell, i'll throw a party. But i wouldn't hold your breath for this to happen. :) --Dan
Re: Some thoughts and quetsions about the data flow infrastructure
On 2/13/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote: > There are certainly performance issues here. There are limits on > how much I, and the others who have worked on this have been able to > change before we do our merge. So far, only those passes that were > directly hacked into flow, such as dce, and auto-inc-dec detection > have been rewritten from the ground up to fully utilize the new > framework. However, it had gotten to the point where the two > frameworks really should not coexist. Both implementations expect > to work in an environment where the information is maintained from > pass to pass and doing with two systems was not workable. So the > plan accepted by the steering committee accommodates the wholesale > replacement of the dataflow analysis but even after the merge, there > will still be many passes that will be changed. Does it means that compiler will be even more slower? No, it will mean the compiler will be faster. Sooner if you help. You seem to believe that the DF infrastructure is fundamentally slower than flow is. I believe that there are other reasons for the current differences in compile time. AFAICT the current compile time slowdowns on the dataflow branch are due to: * bitmaps bitmaps bitmaps. We badly need a faster bitmap implementation. * duplicate work on insns scanning: 1. DF scans all insns and makes available accurate information 2. Many (most) passes see it and think, "Hey, I can do that myself!", and they rescan all insns for no good reason. The new passes, that use the new infrastructure, are among the fastest in the RTL path right now. The slow passes are the passes doing their own thing (CSE, GCSE, regmove, etc.). * duplicate work between passes (minor): - on the trunk, regmove can make auto increment insns - on the df branch, the auto-inc-dec pass makes those transformations redundant * earlier availability of liveness information: - On the trunk we compute liveness for the first time just before combine - On the dataflow branch, we have liveness already after the first CSE pass Updating it between CSE and combine over ~20 passes is probably costly compared to doing nothing on the trunk. (I believe having cfglayout mode early in the compiler will help reduce this cost thanks to no iterations in cleanup_cfg) Maybe I overestimate the cost of some of these items, and maybe I'm missing a few items. But the message is the same: There is still considerable potential for speeding up GCC using the new dataflow infrastructure. Gr. Steven
Re: Some thoughts and quetsions about the data flow infrastracture
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes: > I know some work is being done on incremental df analysis. It could > decrease time for rescanning RTL between passes. Let us hope on this. My understanding is that on dataflow-branch the DF information is now fully incremental. I don't really grasp where you are headed with this criticism. Criticism can be a good thing. But I think it would help me, at least, if you were more clear about what you see as the alternative. Moving all the RTL passes into tree-ssa might be a good idea. But it would be orders of magnitude more work than the dataflow work has required, so it is not comparable. We could contrain the dataflow work to be a 100% improvement on all platforms before it can be committed. But that would be extremely difficult, because they would continually be catching up to problems introduced in mainline. For example, I slowed them down by a few days as they fit my recent lower-subreg.c patch into the DF framework. So I think that imposing such a requirement would be unwise. I believe it would be tantamount to saying that we can never make a major infrastructure change. For tree-ssa (admittedly a much bigger change) we accepted slowdowns when it was committed because we believed that the end result would be better. I think that you should channel your concern into looking at the code on dataflow-branch and seeing how it can be improved, or determining that it is hopeless. I don't think this is a discussion which can be usefully carried on in the abstract. Ian
Re: Pre Compiled Headers
Hello
On Mon, 12 Feb 2007 19:46:35 -0800 Mike Stump wrote
> The mental model you should use for PCH is this, when processing a header,
> the compiler does a complete memory walk and dumps it to a file. Upon
> `reading' the pch file, it mmaps all that memory back in, throwing out all
> previously allocated memory, and continues just after the #include.
A big thanks for the explanation, which is something I partly guessed, but
which leaves me in a deep trouble :-)
what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.
It seems to me that some such GTY-ed global data might explicily want not to
be reloaded, or maybe want to be always cleeared at each pch reload.
However, I am not sure there is any GTY tag for this.
I also don't understand at which point of the compilation is the PCH dumped.
For example, do PCH file contain Gimple-SSA trees (I would guess yes) or
only Generic trees?
Maybe such precious knowledge about GTY & PCH should go into the
documentation or the wiki? I did't found much information on this in
http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html
A big thanks to all for the information. Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Pre Compiled Headers
what happens with the data previously loaded by a previous pch include file? I can't figure out why every GTY()-ed global data (extern or static) should be overwritten at each PCH inclusion, but then maybe I am wrong. There can be only one PCH inclusion in every compilation. Paolo
