Re: Designs for better debug info in GCC
On Nov 24, 2007 5:54 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > Apparently, you can't treat DEBUG_INSN just like any other normal > > insn. > > Obviously not. They're weaker uses than anything else. We haven't > had any such thing in the compiler before. So we get a "third way". GCC has insns and notes, and now it gets a third object to deal with in the insns stream. And it has to handle this new case everywhere. To me it seems that your approach will not help to make GCC easier to work with and understand. Unless there are compelling reasons to do this, I think this is a step in the wrong direction. > > but for the moment I fear you're just going to see a lot of > > duplication of ugly conditionals > > Your fear is understandable but not justified. Go look at the > patches. x86_64-linux-gnu now bootstraps and produces exactly the > same code with and without -fvar-tracking-assignments. And no complex > conditionals were needed. The most I've needed so far was to ignore > debug insns at certain spots. I didn't say "complex conditionals" but ugly conditionals ;-) I mean all the "INSN_P && ! DEBUG_INSN_P" conditionals. There seem to be a lot of those, and it's not immediately obvious where and when you'd need them. > > and bugs where such conditionals are forgotten/overlooked/missing. > > See above. One of the reasons for the approach I've taken is that > such cases will, in the worst case, cause missed optimizations, not > incorrect compiler output. Ah! More on that later. > > And the benefit, well, let's just say I'm not convinced that less > > elaborate efforts are not sufficient. > > Sufficient for what? Efforts towards what? Generating more incorrect > debug information just for the sake of it? Adding more debug > information while breaking some that's just fine now? Is that really > progress? Ah, there you go again with this extremist pro-debug-info stance. How can one argue with you when you keep ridiculing other points of view using ridiculous arguments? Who said anything about "generating more incorrect information just for the sake of it"? I don't think anyone did. The "for the sake of it" part is just offensive. You seem imply that people are arguing gcc should emit wrong debug information on purpose. Please step out of your own world of thoughts for a second, and try to understand that other people can have a different but nevertheless reasonable point of view. I think it is impossible to get perfect debug info after very complex code transformations. And because of that, I also think it is reasonable to not get perfect debug info in less complex cases. Your colleague expressed perfectly how I define "sufficiently good debug info": "It needs to be good enough that a semi-knowledgable person or a dumb but heuristic-laden program that processes debugging info can nevertheless extract reliable information." (http://gcc.gnu.org/ml/gcc/2007-11/msg00581.html) Note how this "good enough" does not imply correctness at all cost". Here is another "extremist" point of view: Correctness for a optimization algorithm means that it does not miss optimization opportunities that it is designed to catch. Therefore if an optimization algorithm implementation misses an optimization that it should catch, then this is a correctness issue. ;-) You said you now get the same code with and without -fvar-tracking-assignments on your branch. Can you also prove that the branch does not introduce new missed optimizations wrt. the latest revision that you merged from the trunk? Gr. Steven
Autovectorizing HIRLAM; some progress.
L.S., I noticed some unexpected progress last night (as opposed to about a week ago). Previous figures: 5316 loops vectorized 6060 loops not vectorized New figures: 5188 loops vectorized 6189 loops not vectorized i.e., 201 loops *more* recognized by the vectorizer, of which 72 got vectorized, 129 not. As I see no activity (svn-wise) on the vectorizer front, it probably is the better alias analysis by Richard Guenther ... -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: Autovectorizing HIRLAM; some progress.
I wrote: 5188 loops vectorized Dang ! Should be 5388 of course, otherwise the math doesn't add up. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: Designs for better debug info in GCC
On Nov 24, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007 5:54 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> > Apparently, you can't treat DEBUG_INSN just like any other normal >> > insn. >> >> Obviously not. They're weaker uses than anything else. We haven't >> had any such thing in the compiler before. > So we get a "third way". GCC has insns and notes, and now it gets a > third object to deal with in the insns stream. Not quite. It's an insn. But it is different in some ways. It's not unheard of. Asm insns are also different in some ways. USEs and CLOBBERs too. Delayed-branch instruction groups too. It would be great if infrastructure for weak uses was already in place, but if it's needed (we haven't determined that, but I'm convinced there's no better way) and it isn't there, then it has to be put in. > And it has to handle this new case everywhere. I've already explained why this isn't true. It's not even close to being true. In fact, I've chosen this representation *precisely* because I reasoned it would lead to the least global impact. Of course you can refuse to believe that and point at the changes I had to make as alleged counter-proof, failing to notice how many other locations I haven't had to change and that just work because adjusting other instructions after transformations is precisely what all transformation passes already do. > I didn't say "complex conditionals" but ugly conditionals ;-) > I mean all the "INSN_P && ! DEBUG_INSN_P" conditionals. Oh, that's easy: NON_DEBUG_INSN_P can simplify that. There are, what, a few dozens of such tests in the compiler right now, compared with the hundreds of tests for INSN_P and a few tens of tests for DEBUG_INSN_P. I didn't think it was worth creating yet another macro, but if you find this so unacceptable, maybe I can rework it. Would you prefer NON_DEBUG_INSN_P, or would you prefer the original INSN_P and all uses thereof to be spelled differently, just to keep the few objectionable INSN_P && ! DEBUG_INSN_P tests more beautiful? >> Sufficient for what? Efforts towards what? Generating more incorrect >> debug information just for the sake of it? Adding more debug >> information while breaking some that's just fine now? Is that really >> progress? > Ah, there you go again with this extremist pro-debug-info stance. How > can one argue with you when you keep ridiculing other points of view > using ridiculous arguments? Who said anything about "generating more > incorrect information just for the sake of it"? Getting even the trivial cases wrong and dismissing those without realizing how things would fall apart in the big picture looks like "generating more incorrect information just for the sake of it" to me. Now, maybe it's not. Maybe it's just human behavior, a wish that some simpler solution will take care of a problem and that the simple counter-examples I've pointed out are rare situations. I don't see that they are. I've put a lot of thought into this problem, I've been working on it for quite a long time, and I've fallen in many of the traps that I pointed out, and avoided several others. I realize I come off as arrogant when I feel cornered by a majority that obviously hasn't spent enough on the issue to realize the obvious-to-me major problems with the alternatives that are on the table. I realize in such situations I often react in ways that are detrimental to the points I'm trying to make. I realize this doesn't help. I hope people can see through the mess of proposal-name-calling that this is turning into. > The "for the sake of it" part is just offensive. I agree, and I apologize for that. It's been a very frustrating debate. > You seem imply that people are arguing gcc should emit wrong debug > information on purpose. That's how it feels to me when the claims come up that it's not a matter of correctness, or that it's not important to get it right. > Your colleague expressed perfectly how I define "sufficiently good > debug info": > "It needs to be good enough > that a semi-knowledgable person or a dumb but heuristic-laden program > that processes debugging info can nevertheless extract reliable > information." > (http://gcc.gnu.org/ml/gcc/2007-11/msg00581.html) I'm very happy you agree with him. Unfortunately, you appear to be focusing on the sloppiness afforded by the wording "good enough", and assuming that this can be pushed beyond the point of "extract *reliable* information", which is the key operative qualifier here. If it's "good enough" for other purposes, but it's not possible to "extract reliable information from debugging info", then we don't satisfy the predicate above. That's why I'm aiming at correctness (it's reliable) rather than completeness (optimizations can discard stuff). > Here is another "extremist" point of view: > Correctness for a optimization algorithm means that it does not miss > optimization opportunities that it is designed to c
Re: Designs for better debug info in GCC
On Nov 24, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: >> Yes, catching all such cases hasn't been trivial. If we miss some, >> then what happens is that -O2 -g -fvar-tracking-assignments outputs >> different executable code than -O2. > But that's a very serious type of bug because it means you have > situations where a program fails and you can't debug it because when > you turn on debugging information, it doesn't fail anymore. We need > to make an absolute rule that this *cannot* happen and luckily this is > one of the easiest types of errors to project against. I agree completely. That's why I've gone to such great lengths to ensure these errors are easily testable in my implementation, and to put all my changes under control of a command-line option. Then, you can still get (poorer) debug information by disabling (or not enabling) this option. And then, despite the consensus that GCC must not generate different code with and without -g, the patch that fixes one such regression has been lingering for months, and the patch that introduced the regression hasn't been reverted either. Besides, the Ada RTS compiles differently with -g than without -g, such that compare-debug doesn't pass if you compare sysdep.o. Nobody but me seems to care. I'm sure I'm going to find other differences between -g and -g0 once I fix this and bootstrap4-debug gets past this point and builds other target libraries. I'm not looking forward to the discussions that will ensue if any fixes for these problems imply any costs whatsoever, given the experience I've had with the SSA-coalescing and the optimize-basic-blocks issues that are all about debug information versus optimization :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Nov 24, 2007 4:00 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > > > And it has to handle this new case everywhere. > > I've already explained why this isn't true. It's not even close to > being true. In fact, I've chosen this representation *precisely* > because I reasoned it would lead to the least global impact. Of > course you can refuse to believe that and point at the changes I had > to make as alleged counter-proof, failing to notice how many other > locations I haven't had to change and that just work because adjusting > other instructions after transformations is precisely what all > transformation passes already do. It also makes some things easier - for example during inlining of a function body we re-map all DECLs in the inlined copy. With an on-the-side representation you have to ensure to make the same mapping explicitly, with DEBUG_INSNs the mapping is automatically done during the copying of the IL. A similar problem with using SSA_NAME definition points to store information is using the renamer to rename a variable that already has SSA_NAMES (which is IMHO bogus, as we do not detect the errorneous case of overlapping life-ranges - but ignore that for now) - in this case you need some magic to transfer the on-the-side debug information from the old SSA_NAMEs to the new ones (where possible). Just to mention a few problems we are running into ;) Richard.
Re: Designs for better debug info in GCC
Alexandre Oliva wrote: > And then, despite the consensus that GCC must not generate different > code with and without -g, the patch that fixes one such regression has > been lingering for months, and the patch that introduced the > regression hasn't been reverted either. Pointers? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: Designs for better debug info in GCC
> Besides, the Ada RTS compiles differently with -g than without -g, > such that compare-debug doesn't pass if you compare sysdep.o. Nobody > but me seems to care. That's wierd. Except on Windows, VXWorks, and VMS, there's almost no code in that file.
Re: Status of GCC 4.3 on SPARC (Debian)
> I recently compiled the entire Debian archive (around 6500 packages > that need to be compiled) on SPARC using trunk to identify new issues > before GCC 4.3 is released. I compiled the archive twice, once with > default optimization levels specified by packages and once with > optimization set to -O3. Thanks for doing this! > Thanks to Sun for donating a T2000 to Debian and to OSU's Open Source > Lab for hosting the machine. Seconded. :-) -- Eric Botcazou
Re: Designs for better debug info in GCC
On Nov 24, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: >> Besides, the Ada RTS compiles differently with -g than without -g, >> such that compare-debug doesn't pass if you compare sysdep.o. Nobody >> but me seems to care. > That's wierd. Except on Windows, VXWorks, and VMS, there's almost > no code in that file. Yep. On GNU/Linux, the difference is precisely that, when compiling with -g, you get the variables that represent the file open modes to the output, while compiling without -g they're completely optimized away. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Nov 24, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> And then, despite the consensus that GCC must not generate different >> code with and without -g, the patch that fixes one such regression has >> been lingering for months, and the patch that introduced the >> regression hasn't been reverted either. > Pointers? Regression introduced here: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html first reported here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00127.html last proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00608.html -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Nov 12, 2007, Joe Buck <[EMAIL PROTECTED]> wrote: > consider dropping observable points where the states will not match. We can't really do that. The line number mapping is from PC to line number, regardless of how far into the execution or earlier lines the code is. Omitting certain mappings from PC to line numbers would be wrong. The piece of the puzzle we're still missing is how to get debuggers clever enough to decide where to set a breakpoint. Nowadays, debuggers (at least those I'm familiar with) tend to set breakpoints at the lowest-numbered PC corresponding to a given source line number. While this is useful at times, at other times what you want is the lowest PC after all instructions corresponding to the previous line, because at that point you know all the state of the previous line should be stable and hopefully still observable. Or something along these lines. I don't have a complete solution for this problem. It's very far from trivial, and I don't see that debug information can carry enough information for the compiler to aid the debugger in selecting where to place breakpoints in this regard. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Nov 24, 2007 9:19 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > > > Alexandre Oliva wrote: > >> And then, despite the consensus that GCC must not generate different > >> code with and without -g, the patch that fixes one such regression has > >> been lingering for months, and the patch that introduced the > >> regression hasn't been reverted either. > > > Pointers? > > Regression introduced here: > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html > > first reported here: > > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00127.html > > last proposed patch here: > > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00608.html Well - it's a workaround for a bug that's elsewhere. Generated code shouldn't change if we allocate extra DECL_UIDs, but only possibly if we change DECL_UID ordering. (If that is the problem, as I remember your analysis) Richard.
Re: Designs for better debug info in GCC
> The piece of the puzzle we're still missing is how to get debuggers > clever enough to decide where to set a breakpoint. Nowadays, debuggers > (at least those I'm familiar with) tend to set breakpoints at the > lowest-numbered PC corresponding to a given source line number. While > this is useful at times, at other times what you want is the lowest PC > after all instructions corresponding to the previous line, because at > that point you know all the state of the previous line should be stable > and hopefully still observable. Or something along these lines. I don't > have a complete solution for this problem. It's very far from trivial, > and I don't see that debug information can carry enough information for > the compiler to aid the debugger in selecting where to place breakpoints > in this regard. Or you want the first instruction of that line that shows the actual flow of control. Or sometimes other things, as you say. A few of us were discussing this issue in person last week and we strongly agree with your characterization that it's very far from trivial. The consensus we came to is that the compiler should continue associating the original line number with each instruction that came from it, but perhaps should also provide additional, not-yet-defined annotations to allow the debugger to be able to provide various different types of breakpoints, corresponding to various purposes the programmer us using the breakpoints for.
Re: Progress on GCC plugins ?
On Nov 17, 2007, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > I had no trouble getting students up to spead on well-structured > plugable proprietary compiler within weeks. However, the same > experience on GCC has proven much less impressive results. > Consequently, we have been making more progress working with > proprietary compiler than with GCC -- something I find myself > embarrasing :-( That's sad, but adding to GCC the ability to support plugins (I assume this is about dynamically-loaded GCC passes) won't change this at all. The thing that people have historically found difficult in getting started with GCC is that there was a lot of infrastructure that didn't follow the patterns and algorithms found in compiler literature. This has changed a bit with the Tree-SSA infrastructure, not only because SSA and GIMPLE-like representations are commonplace, but also because there aren't as many inter-dependencies and implicit assumptions between passes as there used to be with RTL. But it's still true that one has to learn a lot about GCC internals before one can write a new RTL pass, and even a new Tree-SSA pass. Merely introducing means for people to dynamically load passes won't change this. Only designing a plugin API that hides a lot of GCC's internal complexity, while still making room for useful experiments, would make this plugin API useful to address this problem. But then, this is much harder than just adding plugin support, and I'm familiar with any actual proposals that would address the underlying problem. And then, once the underlying problem is addressed and we have an API that is usable by regular users, maybe we will find out that we don't need plugins, after all. That, as Diego and Ian say, adding plugin support is trivial, but I'm pretty sure that's not where the actual problem lies. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Progress on GCC plugins ?
On Nov 16, 2007, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > For example, the "simple" plugin mechanism many people have implicitly > in mind is just: something give you the ability to call a dlsymed > function inside a dlopened plugin as a pass in a defined (& fixed) > position in passes.c. I tend to believe it is not that difficult to > implement (it seems to me that the issue is to get it accepted in the > trunk). However, this does not guaranty at all that all the internal > representation (e.g. the tree.h and other header files) is stable. Exactly. And I guess some of this could even be accomplished with LD_PRELOAD. But how useful would that be, really? How far would this go into addressing the real needs that are behind the requests for plugin support? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Progress on GCC plugins ?
> And then, once the underlying problem is addressed and we have an API > that is usable by regular users, maybe we will find out that we don't > need plugins, after all. That, as Diego and Ian say, adding plugin > support is trivial, but I'm pretty sure that's not where the actual > problem lies. That's my position as well. AND that plugin (here meaning dynamic link) support creates tricky legal issues that the RMS has not been willing to deal with in the past.
Re: Progress on GCC plugins ?
On Nov 15, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote: > If/when your pass reaches certain maturity, you think it's ready for > production, and people think it's a good idea to have it in the > compiler, then you convert it into a static pass and you go through > the traditional bootstrap process. > That's the core idea with plug-ins, they allow more flexibility for > experimentation. They are not a means for implementing permanent > features in the compiler. I find the two paragraphs above contradictory. If they're not means for implementing permanent features, then converting a pass implemented as a plugin that's ready for production into a static pass is what? It raises an issue of how important it is that this plugin architecture, if it is to exist, be similar to the internals of GCC, such that the conversion is as simple as possible. OTOH, the more GCC internals it relies on, the less useful it is to abstract away GCC's internal complexities. Looks like conflicting goals to me :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Progress on GCC plugins ?
Alexandre Oliva wrote: On Nov 15, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote: If/when your pass reaches certain maturity, you think it's ready for production, and people think it's a good idea to have it in the compiler, then you convert it into a static pass and you go through the traditional bootstrap process. That's the core idea with plug-ins, they allow more flexibility for experimentation. They are not a means for implementing permanent features in the compiler. I find the two paragraphs above contradictory. If they're not means for implementing permanent features, then converting a pass implemented as a plugin that's ready for production into a static pass is what? Converting a pass implemented as a plug-in into a static pass is the way to add permanent feature in the compiler. In principle, I don't think we'll want to implement permanent features as plug-ins. It raises an issue of how important it is that this plugin architecture, if it is to exist, be similar to the internals of GCC, such that the conversion is as simple as possible. There is no conversion. Read Sean Callanan's paper in this year's GCC Summit proceedings. Plug-in code uses the same internal code as statically linked passes. Diego.
Re: Progress on GCC plugins ?
On Nov 7, 2007, Brendon Costa <[EMAIL PROTECTED]> wrote: > If the license extends to the data generated by GPL apps It doesn't, AFAIK, but IANAL. But the issue is not so much the specific data, but the format in which the data is and the reasons behind choosing that format. The FSF might successfully present to a court an argument such as: Look, Your Honor, it is quite obvious that the code in question was developed to work as a single program, and that the separation through the intermedia representation layer is just an attempt to escape the conditions of the license of the program they based their work on. Please don't permit the defendant to keep on distributing that code without complying with the license conditions. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Progress on GCC plugins ?
On Nov 24, 2007, at 1:54 PM, Alexandre Oliva wrote: On Nov 16, 2007, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: For example, the "simple" plugin mechanism many people have implicitly in mind is just: something give you the ability to call a dlsymed function inside a dlopened plugin as a pass in a defined (& fixed) position in passes.c. I tend to believe it is not that difficult to implement (it seems to me that the issue is to get it accepted in the trunk). However, this does not guaranty at all that all the internal representation (e.g. the tree.h and other header files) is stable. Exactly. And I guess some of this could even be accomplished with LD_PRELOAD. But how useful would that be, really? How far would this go into addressing the real needs that are behind the requests for plugin support? Full "plugin support" really encompasses more than having GCC just being able to dlopen a .so file. It means providing (hopefully) well defined extension points for common operations. For example, it should be relatively easy to load a plugin that defines a new tree-ssa pass, and have it get dropped naturally into the pass manager. Alternatively, you could have an extension point for "gimple consumers" that don't care about the optimizer or backend, but just want a way to parse the code and deal with the gimple or generic trees. Examples of this would be static analysis tools or things like the "FFI generator" for scripting languages. To me personally, I'm looking forward to this happening because it means that "llvm-gcc" could conceptually just become a plugin into a standard GCC: the llvm-gcc plugin would use exactly the same extension point as the "static analysis tools" (it doesn't care about the GCC optimizer or backend, so it just wouldn't use it). This would make it potentially easier to deploy the llvm-gcc binary (it's a plugin for a specific gcc, instead of an entire copy of gcc itself), and it would potentially make it easier to keep the tree up to date as GCC moves forward. For the record, I'm fine everything being GPL, the license is not the issue. -Chris
Re: Progress on GCC plugins ?
On Nov 24, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> On Nov 15, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote: >> >>> If/when your pass reaches certain maturity, you think it's ready for >>> production, and people think it's a good idea to have it in the >>> compiler, then you convert it into a static pass and you go through >>> the traditional bootstrap process. >> >>> That's the core idea with plug-ins, they allow more flexibility for >>> experimentation. They are not a means for implementing permanent >>> features in the compiler. >> >> I find the two paragraphs above contradictory. If they're not means >> for implementing permanent features, then converting a pass >> implemented as a plugin that's ready for production into a static pass >> is what? > Converting a pass implemented as a plug-in into a static pass is the > way to add permanent feature in the compiler. In principle, I don't > think we'll want to implement permanent features as plug-ins. Agreed. >> It raises an issue of how important it is that this plugin >> architecture, if it is to exist, be similar to the internals of GCC, >> such that the conversion is as simple as possible. > There is no conversion. Then I guess I don't see any value whatsoever in this particular plugin architecture in overcoming the difficulties unexperienced GCC developers face :-( > Plug-in code uses the same internal code as statically linked > passes. Then they can be means for implementing permanent features in the compiler, after all. I guess we can agree on that ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Nov 24, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: >> Alexandre Oliva wrote: >>> And then, despite the consensus that GCC must not generate different >>> code with and without -g, the patch that fixes one such regression has >>> been lingering for months, and the patch that introduced the >>> regression hasn't been reverted either. >> Pointers? > Regression introduced here: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html > first reported here: > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00127.html > last proposed patch here: > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00608.html I take it back that this patch wasn't approved. Mark had approved it on Nov 5, I didn't want to check it in before going on a trip and, when I returned, I forgot about the approval because it was in an unrelated thread. http://gcc.gnu.org/ml/gcc/2007-11/msg00139.html I'll shortly check in that one and a bunch of others that also got approval but that I deferred until my return. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
Alexandre Oliva wrote: Besides, the Ada RTS compiles differently with -g than without -g, such that compare-debug doesn't pass if you compare sysdep.o. Nobody but me seems to care. We certainly care about this, and appreciate efforts to fix it! Robert Dewar. We = all the GNAT folks.
Re: Designs for better debug info in GCC
On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote: > Generated code shouldn't change if we allocate extra DECL_UIDs, but > only possibly if we change DECL_UID ordering. (If that is the > problem, as I remember your analysis) That is indeed the problem, but I'm not sure your requirement is feasible. If we permit DECL_UID divergence, it means we can't use DECL_UID for hashing any more. Since they already stand for hashable proxies for the decl pointers, I don't see what we'd gain by introducing yet another hashable uid that's stable across -g. What do you suggest us to use for hashing? Or do you suggest us to do away with hashing and use sorted set or map data structures? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Nov 25, 2007 12:28 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote: > > > Generated code shouldn't change if we allocate extra DECL_UIDs, but > > only possibly if we change DECL_UID ordering. (If that is the > > problem, as I remember your analysis) > > That is indeed the problem, but I'm not sure your requirement is > feasible. If we permit DECL_UID divergence, it means we can't use > DECL_UID for hashing any more. Since they already stand for hashable > proxies for the decl pointers, I don't see what we'd gain by > introducing yet another hashable uid that's stable across -g. > > What do you suggest us to use for hashing? Or do you suggest us to do > away with hashing and use sorted set or map data structures? No, hashing is fine, but doing walks over a hashtable when your algorithm depends on ordering is not. I have patches to fix the instance of walking over all referenced vars. Which is in the case of UIDs using bitmaps and a walk over a bitmap (which ensures walks in UID order). Richard.
Re: Designs for better debug info in GCC. Choice A or B?
To imagine that i'm using "-g -Os -finline-functions -funroll-loops". There are differences in how to generate "optimized AND debugged" code. A) Whole-optimized but with dirty debugged information if possible. When there is coredump from crash then its debugged information can be not complete (with losses) but can be readable for humans. This kind of strategy can't work well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is whole-optimized same as stripped program. B) Whole-debugged but partially optimized because of restricted requirements to maintain the full debugged information without losses. This kind of strategy works well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is less whole-optimized and bigger than stripped program. Sincerely, J.C.Pizarro
Re: Designs for better debug info in GCC. Choice A or B?
To imagine that i'm using "-g -Os -finline-functions -funroll-loops". There are differences in how to generate "optimized AND debugged" code. A) Whole-optimized but with dirty debugged information if possible. When there is coredump from crash then its debugged information can be not complete (with losses) but can be readable for humans. This kind of strategy can't work well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is whole-optimized same as stripped program. B) Whole-debugged but partially optimized because of restricted requirements to maintain the full debugged information without losses. This kind of strategy works well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is less whole-optimized and bigger than stripped program. Sincerely, J.C.Pizarro
Re: Designs for better debug info in GCC. Choice A or B?
On Nov 24, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > hat is indeed the problem, but I'm not sure your requirement is > feasible. If we permit DECL_UID divergence, it means we can't use > DECL_UID for hashing any more. Since they already stand for hashable > proxies for the decl pointers, I don't see what we'd gain by > introducing yet another hashable uid that's stable across -g. > > What do you suggest us to use for hashing? Or do you suggest us to do > away with hashing and use sorted set or map data structures? > > -- > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > FSF Latin America Board Member http://www.fsfla.org/ > Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} > Free Software Evangelist [EMAIL PROTECTED], gnu.org} ( i posted this message but doesn't appear in http://gcc.gnu.org/ml/gcc/2007-11/ , i don't know why? ) To imagine that i'm using "-g -Os -finline-functions -funroll-loops". There are differences in how to generate "optimized AND debugged" code. A) Whole-optimized but with dirty debugged information if possible. When there is coredump from crash then its debugged information can be not complete (with losses) but can be readable for humans. This kind of strategy can't work well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is whole-optimized same as stripped program. B) Whole-debugged but partially optimized because of restricted requirements to maintain the full debugged information without losses. This kind of strategy works well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is less whole-optimized and bigger than stripped program. Sincerely, J.C.Pizarro
Re: Autovectorizing HIRLAM; some progress.
> L.S., > > I noticed some unexpected progress last night (as opposed to about a > week ago). > > Previous figures: > > 5316 loops vectorized > 6060 loops not vectorized > > New figures: > > 5188 loops vectorized > 6189 loops not vectorized > > i.e., 201 loops *more* recognized by the vectorizer, of which 72 got > vectorized, 129 not. > cool! > As I see no activity (svn-wise) on the vectorizer front, it probably is > the better alias analysis by Richard Guenther ... > could also be the patch by Sebastian Pop to provide more precise dependence relations when the number of iterations is not known (the fix to PR32377). (would be intereting to see an example for a loop that is now vectorized and didn't vectorize before, if you have that information available) thanks, dorit > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.indiv.nluug.nl/~toon/ > GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: Progress on GCC plugins ?
> The FSF might successfully present to a court an argument such as: > > Look, Your Honor, it is quite obvious that the code in question was > developed to work as a single program, and that the separation > through the intermedia representation layer is just an attempt to > escape the conditions of the license of the program they based their > work on. Please don't permit the defendant to keep on distributing > that code without complying with the license conditions. Yes, such an argument might be successful and indeed many people, including myself, believe it *likely* would be successful, but going to court is in many way a "crap shoot" and it might *not* be successful. If that happened it would set a precedent that could be extended on in a way that would be harmful to Free Software. That's why it's considered far better to try to avoid such a case in the first place. Moreover, if we did this in conjunction with a carefully-defined API, the defendant could argue that the purpose of that API was precisely to *not* have it be viewed as a single program, so the result of such a case would be far less certain. As was pointed out here numerous times, 90+% of the difficulty in working with is the difficulty in understanding the inherently-complex algorithmic structure of the compiler and its data structures (no real-world compiler will ever be able to use algorithms unmodified from a textbook) coupled with limited documentation. Doing something to make the remaining few percent easier will not, in my opinion, increase the participation in GCC enough to justify the legal risk to Free Software.
Re: Designs for better debug info in GCC. Choice A or B?
The incomplete information (with losses) from A) doesn't mean BAD design. This is as a paradox of compression, A) for lossy compressors like JPEG, MP3, Ogg/Vorbis, MPEG, ... and B) for lossless data compressors like PNG, GIF, zip, gzip, bzip2, rar, 7z, ... You will understand quickly the meaning of both choices. Sincerely, J.C.Pizarro
