Re: g77 problem for octave
This is just the case. The problem is not if I like or not. Actually, i am happy with gfortran. But the package i want to use requires the specific version g77 4.1.0-25. If there is no solution, then i will uninstall gcc 4.1.0-25 and all dependent components and will install gcc 3.3.4 for which i can find g77. But i think this is a very time consuming work. Thanks, Kind regards, Tolga Yapici > On 7/16/06, Tim Prince <[EMAIL PROTECTED]> wrote: > > > On my computer, the installed version of gcc is 4.1.0-25 and i could not > > > find any compatible version of g77 to install. For the installation of > > > octave, i need exactly gcc-g77 not gcc-fortran. > (...) > > If you are so interested in using g77 rather than gfortran, it should be > > easy enough to grab gcc-3.4.x sources and build g77. One would wonder > > why you dislike gfortran so much. > > I don't think he dislikes gfortran so much, he just needs _that_ > specific version of the package to install octave, I guess. > > That would be a SuSE packaging problem, so I'm CC:'ing matz. > > Gr. > Steven
Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
Some people call this "uninlining". I've also heard the term "procedural abstraction". The generalization is to identify common code fragments that can be turned into functions. Then, replace the users of the common code with function calls. Is this the same as Code Factoring? http://gcc.gnu.org/projects/cfo.html Best Regards, Rafael
Re: Calling gimplify_to_stmt_list (...) on a statement containing a TARGET_MEM_REF node
Hello, > Roberto COSTA wrote: > > Andrew Pinski wrote: > >> On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote: > >> > >>> Is it a bug... or am I trying to do something wrong? > >> > >> Why are you trying to regimplify something which is in gimple? > > > > I'm trying to generate new code, which happens to contain TARGET_MEM_REF. > > To do that, I find more convenient to generate a big and deep tree and > > to gimplify it later (I saw other passes follow this approach). > > Passes that absolutely need to do it, should, others probably shouldn't. > It generally is a waste of time and memory to do it if your pass can > simply generate piecewise GIMPLE expressions on it's own. > > Anyway, ignoring Andrew's tangent for a moment, this is a bug. not really a bug, just the gimplifying of TARGET_MEM_REFs was not implemented (since nobody needed it so far). Zdenek
Re: local data flow
Joern Rennecke wrote: > In http://gcc.gnu.org/ml/gcc/2006-07/msg00390.html, you write: > >> depending on what you are doing, you can update the solution in place. >> The point of the dataflow talk was not to say that you cannot do >> anything incremental, it was to say that there are no good GENERAL >> techniques. Many times it is possible to update the solution precisely >> if you have a very good understanding of the local conditions under >> which the transformation is done on. >> > > Right. So the struct-equiv code does not have to be converted to > use def-use chains to be beter integrated with thedataflow branch, > it can happily go on using regsets of live registers. > What it needed is a solid understanding about what invariants are > required and how we can maintain them while we are changing the rtl, > in order to keep the cost of updating the information under control. > Which, ironically, is what I proposed to use in the first place outside > of the dataflow branch to address the compile time problems, but Berndt > considerd that approach to fragile. > > > It is fragile, but not in the normal sense. It cannot be generalized to work with any general transformation. You will end up with something that only works for the kinds of transformations that you are doing in the pass you are writing. This is fine. I should point out that you will also not be able to cure cancer with this. You just have to be satisfied to do a good job solving the problem at hand. >> The other trick it to do what I do in the new fast dce or the if-cvt on >> the dataflow branch: >> order the basic blocks so that it does not matter if you mess up the >> solution. Generally a post order or a reverse postorder traversial of >> the basic blocks will have the property that you can just mess things up >> in a wave that moves from the beginning to the end or the end to the end >> of the program without ever seeing the mess you make. >> > > cross-jumping two entire basic blocks creates opportunities for further > cross-jumping and jump simplification involving the predecessor blocks. > This appears to fit a reverse postorder traversal. > > However, if-conversion creates further if-conversion opportunities involving > the newly merged block. Thus, while a postorder / reverse postorder > traversal makes sense, we also need valid information for the newly merged > block, its successors and predecessors. > I suppose reg-live-at-start / reg-live-at-end information is actually easier > to maintain during if-conversion that def-use chains. > > This is true, certainly in theory, a lot less so in practice. The way that you order things is this. while (something changes and we have not done too many passes) do the analysis do one properly ordered pass over the cfg changing what you can change without using information that has been corrupted during this pass. You should limit the number of passes to some small number times the optimization level. you only iterate if you made changes during that pass. You try to keep the dataflow up-to-date. If some transformation is too hard to do this, you mark the block as not transformable until the next pass. In practice, there are few second order effects so you end up iterating twice. I think that what you want is something like the reaching uses problem but you want a forwards version of this rather than a backwards version as is defined in df-problems.c. > ... > >> the gen set of the reaching uses problem is the set of uses. the kill >> set are the defs and the clobbers. This is why the problem is called >> "reaching uses". >> > > In my problem, the gen set is the set of uses, and the kill set are > defs, clobbers and uses. Hence, it's still backwards problem. > > You could define it either way. However, the backwards problem is already there in both the mainline and the dataflow branch. It is called reaching uses or DF_RU. > But it is not really useful to compute this just for one or two code > transformations - benefits could only be obtained if this information > can be kept usable between different transformation to reduce the number > of global updates. > > You have to let it go. This is why we defined it the way we did. Just compute it, use it, and throw it away when you are finished. It is way too hard to figure out how to keep this up to date for all of the passes. > I suppose I should instead continue to operate on regsets, but keep them > usable without frequent global updates, if that's all right with Berndt. > I think you should look closely are DF_RU.
Re: local data flow
Kenneth Zadeck wrote: I suppose reg-live-at-start / reg-live-at-end information is actually easier to maintain during if-conversion that def-use chains. This is true, certainly in theory, a lot less so in practice. The way that you order things is this. while (something changes and we have not done too many passes) do the analysis do one properly ordered pass over the cfg changing what you can change without using information that has been corrupted during this pass. Except that with the current def-use chains updating def-use chains is pointless since they don't have the required information in the first place. In my problem, the gen set is the set of uses, and the kill set are defs, clobbers and uses. Hence, it's still backwards problem. You could define it either way. However, the backwards problem is already there in both the mainline and the dataflow branch. It is called reaching uses or DF_RU. When the block has one or more uses, but no def of a register, the question to ask is 'which uses of this register reaches this *use* site' (backwards). That's different from DF_RU, which calculates this information for def sites instead. I think you should look closely are DF_RU. What more is there to see? When the block I'm looking at only has uses of a register, I don't want to know about uses in 'siblings' in the control flow graph - what I want to know is if the register is live at the end of the block. LR should answer that, and I can keep this information up-to-date inasmuch as it will mention all live registers, and remain self-consistent.
Gcov: Counting lines of source code (untested files) as gcov does
Hi all! I'm currently implementing code coverage analysis in an existing build system. The code tree the system builds consists of "modules" where some code (and files) is covered by tests and some are not. To be able to present statistics "per module" I need to know how many lines of source code there is in the files that are not tested (and therefore have no .da file (I, have to, use gcc 3.3.6)). I've tried a couple of tools but to generate a fair avarage "per module" I need the tool to count lines as gcov does, which they don't. The untested files are compiled with --fprofile-arcs and -ftest-coverage so they do have .bb and .bbg files (again, I use Gcc 3.3.6) so my thinking is to extract the part of gcov.c that count source code lines and create my own tool to do this by reading the bb-file. But I've found that this is a bit "hairy" (is that an expression in english? ;)) as gcov.c depends on a bunch of other gcc files. And I suck at c to, by the way. Has anyone faced, and solved, this problem before? Perhaps someone already has created a tools that does what I need? Or does anyone has any general tips if I go forward with extracting the code from gcov.c? Thanks! Regards, Fredrik Johansson
Re: g77 problem for octave
Hi, On Sun, 16 Jul 2006, Steven Bosscher wrote: > On 7/16/06, Tim Prince <[EMAIL PROTECTED]> wrote: > > > On my computer, the installed version of gcc is 4.1.0-25 and i could not > > > find any compatible version of g77 to install. For the installation of > > > octave, i need exactly gcc-g77 not gcc-fortran. > (...) > > If you are so interested in using g77 rather than gfortran, it should be > > easy enough to grab gcc-3.4.x sources and build g77. One would wonder > > why you dislike gfortran so much. > > I don't think he dislikes gfortran so much, he just needs _that_ > specific version of the package to install octave, I guess. > > That would be a SuSE packaging problem, so I'm CC:'ing matz. [offtopic, but hey] Try compat-g77. It's only on DVD and FTP, not on the CDs. Ciao, Michael.
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >>> I suppose reg-live-at-start / reg-live-at-end information is >>> actually easier >>> to maintain during if-conversion that def-use chains. >> This is true, certainly in theory, a lot less so in practice. >> The way that you order things is this. >> while (something changes and we have not done too many passes) >>do the analysis >>do one properly ordered pass over the cfg changing what you can >> change without using information that has been corrupted during this >> pass. >> >> > Except that with the current def-use chains updating def-use chains is > pointless since they > don't have the required information in the first place. >>> In my problem, the gen set is the set of uses, and the kill set are >>> defs, clobbers and uses. Hence, it's still backwards problem. >> You could define it either way. However, the backwards problem is >> already there in both the mainline and the dataflow branch. It is >> called reaching uses or DF_RU. >> >> > When the block has one or more uses, but no def of a register, the > question > to ask is 'which uses of this register reaches this *use* site' > (backwards). That's > different from DF_RU, which calculates this information for def sites > instead. > >> I think you should look closely are DF_RU. > > What more is there to see? When the block I'm looking at only has > uses of a > register, I don't want to know about uses in 'siblings' in the control > flow graph - > what I want to know is if the register is live at the end of the > block. LR should > answer that, and I can keep this information up-to-date inasmuch as it > will > mention all live registers, and remain self-consistent. > Jorne, I do not know what problem you want to solve. You have never given me or I think anyone else a succinct description of exactly what you want to do here. What you did say that you needed was "No, I want to know if there exists a path from the current *use* of a register to some other *use* of the same register without going through a def. " >From that description I assumed that you really did care which uses actually reached which other uses. The reaching uses problem tracks each use separately. If this isn't what you need then you are free to use LR which is certainly much cheaper than RU.
Importing boehm-gc 6.7?
(I'm not on the list, so please Cc: me on replies, at least for now. This is just a preliminary question. ;) So, gcj still uses boehm-gc 6.3-hacked-to-bits. Is there any chance of bringing it up to date (at least version 6.7)? Doing so *should* make gcj threads [mostly, if not fully] work on NetBSD. gcj-4.1 on NetBSD is near useless, and 4.2 simply segfaults at startup. I've attempted to look at three-way diffs of gc-6.7 <-> gc-6.3 <-> gcj-4.2, but my head hurts. Perhaps a vendor import is really the way to go here, rather than trying to forklift yet more hacks into place...? -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: gcc visibility used by moz
Jason Merrill wrote: OK, you've convinced me that the compiler shouldn't override or complain about explicit visibility attributes. Do you have a problem with implicit propagation of visibility in the absence of an attribute? Specifically: Do you agree with implicitly giving template instantiations the minimum visibility of the template and arguments unless explicitly overridden? Thinking about this further and reading the discussion that's flowed around, I tend to want to change my opinion to say that argument types should not affect the visibility of a symbol at all. It breaks compatibility with existing usage in gcc 4.0/4.1, as well as being a non-obvious change (especially for pointer types, which, absent questions of dynamic casting and RTTI can safely be passed across DSO boundaries). At least in the case of Mozilla, RTTI is a non-issue. Perhaps the compiler should issue a warning in such cases that RTTI may not work correctly. --BDS
Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
Rafael Espíndola wrote: >> Some people call this "uninlining". I've also heard the term >> "procedural abstraction". The generalization is to identify common code >> fragments that can be turned into functions. Then, replace the users of >> the common code with function calls. > > Is this the same as Code Factoring? > http://gcc.gnu.org/projects/cfo.html Yes, that's another name. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: local data flow
Kenneth Zadeck wrote: From that description I assumed that you really did care which uses actually reached which other uses. The reaching uses problem tracks each use separately. If this isn't what you need then you are free to use LR which is certainly much cheaper than RU. Yes, LR is perfectly adequate. I was thinking in terms of def-use chains only because these can be kept more comprehensively up-to-date - i.e. when a register is live in a loop solely because it is used afterwards, and the use after the loop goes away, def-use chains won't keep a lingering livenes of the register in the loop. But since the exiting def-use chains don't actually fit the problem, there is no point in trying to use them here. So, in summary, the plan is: - Use LR (Live Registers) information for if-conversion / cross-jumping. - Update the information after each transformation to keep a correct, but not necessarily minimal solution. - After traversing the entire flowgraph, if anything changed, re-compute LR from scratch. - After re-computing LR, we need to traverse the flowgraph again. This might mean we end up doing more if-conversion / cross-jumping checks than with the current scheme, but since these checks are local, this should be generally cheaper than trying to keep a minimal LR solution all the time. I'm not sure how to best handle splitting blocks when doing cross-jumping. propagate_block can produce inconsistant liveness information for stack regs after reg_stack. Currently this is handled by zeroing out all the stack reg liveness information. Maybe we shouldn't even try to update LR for the split upper parts of the original BBs. The live-at-end information for the joined lower part should be bassically the same as both blocks original BBs had, and doing further optimizations with a partial or fully joined block appears not unlikely; however, the remaining unjoined upper parts of the original BBs are somehow differentfrom each other, so any further cross-jumping for them, while not impossible, seems unlikely - AFAICT it would require a complete corss-jumping of the joined lower part with some other block. So maybe we could mark them has having no valid LR information, and not consider them again till the next global LR recomputation.
Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
Mark Mitchell wrote: > Rafael Espíndola wrote: >>> Some people call this "uninlining". I've also heard the term >>> "procedural abstraction". The generalization is to identify common code >>> fragments that can be turned into functions. Then, replace the users of >>> the common code with function calls. >> Is this the same as Code Factoring? >> http://gcc.gnu.org/projects/cfo.html > > Yes, that's another name. > Although i would hope that a IPA implementation would use a smarter algorithm than what the RTL code factoring is doing (IE we should just value number both functions, and we can then factor up to whatever point the lhs value numbers are the same). --Dan
Re: Importing boehm-gc 6.7?
So, gcj still uses boehm-gc 6.3-hacked-to-bits. Is there any chance of bringing it up to date (at least version 6.7)? I suggest to use boehms-gc branch for public test of 6.7 import, this way you could test how the newer collector operates as a libgcj runtime while I could test it as a host GCC collector at the same time. The test on the branch would help to sort out at least some of the problems before importing it directly to the mainline. How does it sound to you? -- Laurynas
Re: LTO and Code Compaction \ Reverse Inlining \ Procedure Abstraction?
On 7/17/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> Rafael Espíndola wrote:
>>> Some people call this "uninlining". I've also heard the term
>>> "procedural abstraction". The generalization is to identify common code
>>> fragments that can be turned into functions. Then, replace the users of
>>> the common code with function calls.
>> Is this the same as Code Factoring?
>> http://gcc.gnu.org/projects/cfo.html
>
> Yes, that's another name.
>
Although i would hope that a IPA implementation would use a smarter
algorithm than what the RTL code factoring is doing (IE we should just
value number both functions, and we can then factor up to whatever point
the lhs value numbers are the same).
It could even value-number decls based on their mode rather than type, so we
could unify
int foo(int i) { return i; }
long foo(long i) { return i; }
on archs where int == long == SImode.
Richard.
Re: gcc visibility used by moz
Hi, On Sat, 15 Jul 2006, Gabriel Dos Reis wrote: > | I don't see how they get past this issue. I've had some claim, but > | it's a feature, not a bug. > | > | The basic question is, are two unrelated types in different dlls the > | same, just because they have the same name? How do you prevent them > | from being the same? > > it has been a kind of implicit garantee that two classes with external > linkage and with same mangled names refers to the same type. > Implementations have used that property -- which "leaks" into user codes > via type_info::operator== and type_info::before. > > My primary concern is to what extent that guarantee continues to hold > with the visibility stuff and without alienating coding patterns. That's one concern. But what also need to be considered is what if you don't need that guarantee. For instance in an ecosystem where you don't rely on C++ RTTI at all, and instead have your own system (like mozilla seems to have, and KDE has for sure). For those a possibility for Doing The Right thing should be provided without having to care for C++ RTTI (or ideally by providing a working but slow RTTI). Ciao, Michael.
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >> From that description I assumed that you really did care which uses >> actually reached which other uses. The reaching uses problem tracks >> each use separately. If this isn't what you need then you are free to >> use LR which is certainly much cheaper than RU. >> >> > Yes, LR is perfectly adequate. I was thinking in terms of def-use > chains only > because these can be kept more comprehensively up-to-date - i.e. when > a register > is live in a loop solely because it is used afterwards, and the use > after the loop > goes away, def-use chains won't keep a lingering livenes of the > register in the > loop. > But since the exiting def-use chains don't actually fit the problem, > there is no > point in trying to use them here. > > So, in summary, the plan is: > - Use LR (Live Registers) information for if-conversion / cross-jumping. > - Update the information after each transformation to keep a correct, > but not necessarily > minimal solution. > - After traversing the entire flowgraph, if anything changed, > re-compute LR from scratch. > - After re-computing LR, we need to traverse the flowgraph again. > This might mean we > end up doing more if-conversion / cross-jumping checks than with the > current scheme, but > since these checks are local, this should be generally cheaper than > trying to keep a minimal > LR solution all the time. > > I'm not sure how to best handle splitting blocks when doing > cross-jumping. > propagate_block can produce inconsistant liveness information for > stack regs after > reg_stack. Currently this is handled by zeroing out all the stack reg > liveness information. > Maybe we shouldn't even try to update LR for the split upper parts of > the original BBs. > The live-at-end information for the joined lower part should be > bassically the same as both > blocks original BBs had, and doing further optimizations with a > partial or fully joined block > appears not unlikely; however, the remaining unjoined upper parts of > the original BBs > are somehow differentfrom each other, so any further cross-jumping for > them, while not > impossible, seems unlikely - AFAICT it would require a complete > corss-jumping of the joined > lower part with some other block. So maybe we could mark them has > having no valid LR > information, and not consider them again till the next global LR > recomputation. You should do this starting from the dataflow branch. The version of if-cvt there works as I have mentioned in the previous mail and does not use propagate block at all.
Re: Bootstrap broken on ppc-darwin
On Sun, Jul 16, 2006 at 06:05:32PM -0700, Ian Lance Taylor wrote: > Andrew Pinski <[EMAIL PROTECTED]> writes: > > > Here we have the same scope_labelno. The first dbxout_begin_prologue > > comes from calling rs6000_output_mi_thunk. The normal way > > scope_labelno gets incremented is via the > > call to debug_hooks->function_decl in rest_of_handle_final which is > > not done for thunks. > > I don't know if we should call debug_hooks->function_decl for thunks > > or not. > > We shouldn't. It doesn't make sense, since there is no proper > current_function_decl for a thunk. OK. > Previously, scope_labelno was referenced in dbxout_block and > incremented in dbxout_function_end. Both functions are called only by > dbxout_function_decl (a debug hook). So it was always consistent. Yes, that's correct. > Now scope_labelno is used by dbxout_begin_prologue and > dbxout_source_line. Those are both debug hooks themselves. So this > patch has introduced a dependency which was not previously there, > which has led to a bug. Sorry about that, I tried to make sure that scope_labelno was consistent. > There are several ways to fix this, of course. I think the simplest > is going to be to always preincrement scope_labelno in > dbxout_begin_prologue, rather than postincrementing it in > dbxout_function_end. In cases where that fails, we are already in > trouble. I'm testing a patch for this right now. > Note that scope_labelno is now used for two different things: for the > LFBB symbol, and for the Lscope symbol. It does not have to be used > for both, although as far as I can see it does no harm. Using scope_labelno for both cases made the patch clearer. I wanted the patch to be as simple as possible. Sorry I missed thinking about the thunks. I'll get back ASAP when my current patch finishes testing. Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716
Re: local data flow
Kenneth Zadeck wrote: You should do this starting from the dataflow branch. The version of if-cvt there works as I have mentioned in the previous mail and does not use propagate block at all. if-conversion always joins blocks. But cross-jumping merges blocks or partial blocks. If the latter, both of the original blocks are split, and the botom part of the blocks becomes one merge block. You need to re-compute the live-at-end information for the upper parts of the original blocks, which become two separate BBs.
Re: Importing boehm-gc 6.7?
Todd Vierling wrote: (I'm not on the list, so please Cc: me on replies, at least for now. This is just a preliminary question. ;) So, gcj still uses boehm-gc 6.3-hacked-to-bits. Is there any chance of bringing it up to date (at least version 6.7)? Doing so *should* make gcj threads [mostly, if not fully] work on NetBSD. gcj-4.1 on NetBSD is near useless, and 4.2 simply segfaults at startup. I've attempted to look at three-way diffs of gc-6.7 <-> gc-6.3 <-> gcj-4.2, but my head hurts. Perhaps a vendor import is really the way to go here, rather than trying to forklift yet more hacks into place...? A good question. Perhaps the libgcj maintainers would care to comment. David Daney.
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >> >> >> You should do this starting from the dataflow branch. The version of >> if-cvt there works as I have mentioned in the previous mail and does not >> use propagate block at all. >> >> > if-conversion always joins blocks. But cross-jumping merges blocks or > partial blocks. > If the latter, both of the original blocks are split, and the botom > part of the blocks > becomes one merge block. You need to re-compute the live-at-end > information for > the upper parts of the original blocks, which become two separate BBs. > >> >> >> >> > Are you saying that this is a problem with my code or a problem with what you have to do? Updating the LR dataflow when splitting a basic block is generally pretty easy. You start from the end of the block and just interpret the uses and defs for each insn. The code in the new version of if-cvt actually does this where it replaces the old code that used to call propagate block. kenny
Re: local data flow
Kenneth Zadeck wrote: Updating the LR dataflow when splitting a basic block is generally pretty easy. You start from the end of the block and just interpret the uses and defs for each insn. This means duplicating this aspect of the propagate_block functionality. If we really have to do this in multiple places, we should have a function to do that. The code in the new version of if-cvt actually does this where it replaces the old code that used to call propagate block. Even propagate_block clouldn't handle stack regs properly. The problem is that arithmetic operations of implicit pushses / pops, which effectively renames your registers You won't see this problem for passes that run before reg-stack.
Re: gcc vs gnu-classpath
> "Kevin" == Kevin F Quinn <[EMAIL PROTECTED]> writes: Kevin> Hi. Recently (at least in 4.1.1), the classpath pieces bundled with gcc Kevin> include /usr/lib/classpath/libgjsmalsa.so (JNI midi-alsa). This Kevin> creates a conflict when installing gnu-classpath itself. In 4.2 these have moved. I don't think we will back-port this to 4.1, however. In general we avoid changes like that in a given release cycle. Tom
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >> Updating the LR dataflow when splitting a basic block is generally >> pretty easy. You start from the end of the block and just interpret >> the uses and defs >> for each insn. >> >> > This means duplicating this aspect of the propagate_block functionality. > If we really have to do this in multiple places, we should have a > function > to do that. > I have functions for it, look at the code. >> The code in the new version of if-cvt actually does this where it >> replaces the old code that used to call propagate block. >> >> > Even propagate_block clouldn't handle stack regs properly. The > problem is > that arithmetic operations of implicit pushses / pops, which > effectively renames > your registers > You won't see this problem for passes that run before reg-stack. is it really necessary to do your pass after reg stack. Given that there is no if conversion that runs after regstack what is your point? I should point out that there are no passes that currently use any dataflow after regstack.
Re: local data flow
Kenneth Zadeck wrote: is it really necessary to do your pass after reg stack. Given that there is no if conversion that runs after regstack what is your point? I am talking about cross-jumping after regstack. I should point out that there are no passes that currently use any dataflow after regstack. That's because the current cross-jumping is so stupid.
Re: local data flow
Joern RENNECKE wrote: > Kenneth Zadeck wrote: > >> >> >> is it really necessary to do your pass after reg stack. Given that >> there is no if conversion that runs after regstack what is your point? >> >> > I am talking about cross-jumping after regstack. > >> I should point out that there are no passes that currently use any >> dataflow after regstack. >> >> > That's because the current cross-jumping is so stupid. I would be very careful to tread here. regstack is a can of worms and not very good worms. We have had a lot of trouble retrofitting better dataflow into regstack because of the fragile nature of it's implementation. If you think that your cross jumping would be good to do as an interleaved pass to if conversion, it is possible to see the benefit there. However, I think that the code gets hardened a lot by register allocation in it is difficult for me to see how heroic transformations are going to be really useful after that pass. Anyway, many compilers do label the stack and do dataflow on the individual stack elements. GCC is problematic because most of the stack off are set in register allocation, and in truth it really is too late to get much benefit after that pass. But it is not hard to define a problem that did label the stack elements. Kenny
Re: local data flow
Kenneth Zadeck wrote: I would be very careful to tread here. regstack is a can of worms and not very good worms. We have had a lot of trouble retrofitting better dataflow into regstack because of the fragile nature of it's implementation. Well, the approach so far has been 'don't touch change any register allocation for stack regs after reg_stack'. I.e. if cross-jumping sees any stack regs, it considers only literal matches. That should be safe. The only question that arises here is how we should compute the regsets when we split a block. If you think that your cross jumping would be good to do as an interleaved pass to if conversion, it is possible to see the benefit there. There seems to be a misunderstanding here. I have code that is supposed to be used both by if-conversion and by crossjumping. But I have not proposed to run both optimizations interleaved, not am I aware of any benefit that would have. Most of the higher-level if-conversion transformations can only be done before register allocation. Our corss-jumping code is supposed to be run after register allocation, and I suspect running it before register allocation (which I believe would require some changes first) would be rather bad for speed optimizations - basically the antithesis of treegion formation. However, I think that the code gets hardened a lot by register allocation in it is difficult for me to see how heroic transformations are going to be really useful after that pass. Anyway, many compilers do label the stack and do dataflow on the individual stack elements. GCC is problematic because most of the stack off are set in register allocation, and in truth it really is too late to get much benefit after that pass. But it is not hard to define a problem that did label the stack elements. I'm really not very interested in doing optimizations on reg-stack accesses. I just want to be able to do some more intelligent crossjumping, which happens to take place after regstack. Only one processor family uses regstack, and even there it is only relevant in fp-heavy code, and might become obsolescent because of saner IEEE behaviour and pipelinabiliy of SSE instructions.
Re: Bootstrap broken on ppc-darwin
On Sun, Jul 16, 2006 at 06:05:32PM -0700, Ian Lance Taylor wrote:
> Previously, scope_labelno was referenced in dbxout_block and
> incremented in dbxout_function_end. Both functions are called only by
> dbxout_function_decl (a debug hook). So it was always consistent.
>
> Now scope_labelno is used by dbxout_begin_prologue and
> dbxout_source_line. Those are both debug hooks themselves. So this
> patch has introduced a dependency which was not previously there,
> which has led to a bug.
>
> There are several ways to fix this, of course. I think the simplest
> is going to be to always preincrement scope_labelno in
> dbxout_begin_prologue, rather than postincrementing it in
> dbxout_function_end. In cases where that fails, we are already in
> trouble.
>
> Note that scope_labelno is now used for two different things: for the
> LFBB symbol, and for the Lscope symbol. It does not have to be used
> for both, although as far as I can see it does no harm.
The following patch does a pre-increment of scope_labelno in
dbxout_begin_prologue.
No regressions on arm-none-eabi, and I verified the output stabs by
hand. The .Lscope and .LFBB labels start at 1, and increment for each
call to dbxout_begin_prologue.
Andrew, I built a powerpc-darwin cross compiler and manually verified
the output assembly from your testcase. It looks like it should fix your
problem. I don't see any repeated LFBB symbols, where previously I saw
repeated LFBB1 and LFBB4 due to the thunks.
OK to commit?
Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716
2006-07-17 Carlos O'Donell <[EMAIL PROTECTED]>
* dbxout.c (dbxout_function_end): Do not increment scope_labelno.
(dbxout_begin_prologue): Increment scope_labelno.
Index: gcc/dbxout.c
===
--- gcc/dbxout.c(revision 115532)
+++ gcc/dbxout.c(working copy)
@@ -905,7 +905,6 @@ static void
dbxout_function_end (tree decl)
{
char lscope_label_name[100];
- int lscope_labelno = scope_labelno++;
/* The Lscope label must be emitted even if we aren't doing anything
else; dbxout_block needs it. */
@@ -914,8 +913,8 @@ dbxout_function_end (tree decl)
/* Convert Lscope into the appropriate format for local labels in case
the system doesn't insert underscores in front of user generated
labels. */
- ASM_GENERATE_INTERNAL_LABEL (lscope_label_name, "Lscope", lscope_labelno);
- targetm.asm_out.internal_label (asm_out_file, "Lscope", lscope_labelno);
+ ASM_GENERATE_INTERNAL_LABEL (lscope_label_name, "Lscope", scope_labelno);
+ targetm.asm_out.internal_label (asm_out_file, "Lscope", scope_labelno);
/* The N_FUN tag at the end of the function is a GNU extension,
which may be undesirable, and is unnecessary if we do not have
@@ -941,7 +940,7 @@ dbxout_function_end (tree decl)
{
char begin_label[20];
/* Reference current function start using LFBB. */
- ASM_GENERATE_INTERNAL_LABEL (begin_label, "LFBB", lscope_labelno);
+ ASM_GENERATE_INTERNAL_LABEL (begin_label, "LFBB", scope_labelno);
dbxout_begin_empty_stabs (N_FUN);
dbxout_stab_value_label_diff (lscope_label_name, begin_label);
}
@@ -1249,6 +1248,9 @@ dbxout_begin_prologue (unsigned int line
&& !flag_debug_only_used_symbols)
dbxout_stabd (N_BNSYM, 0);
+ /* pre-increment the scope counter */
+ scope_labelno++;
+
dbxout_source_line (lineno, filename);
/* Output function begin block at function scope, referenced
by dbxout_block, dbxout_source_line and dbxout_function_end. */
Re: Bootstrap broken on ppc-darwin
"Carlos O'Donell" <[EMAIL PROTECTED]> writes: > 2006-07-17 Carlos O'Donell <[EMAIL PROTECTED]> > > * dbxout.c (dbxout_function_end): Do not increment scope_labelno. > (dbxout_begin_prologue): Increment scope_labelno. This is OK. Thanks. Isn
Re: config/gnu.h, config/i386/gnu.h don't include copyright notices
Andrew Pinski wrote: Then why does config/rs6000/gnu.h have one, it is more trivial than the others. Different people writing different files at different times making different interpretations of the same rule. Also, sometimes it happens that a file will start as trivial/non-trivial, and then later modifications will change it to non-trivial/trivial, but the patcher doesn't bother to add/remove the copyright notice. Just like sometimes people forget to change the date in the copyright notice. There isn't much point in asking why this happens. If it bothers you, then fix it. If it doesn't bother you, then don't worry about it. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Question of the LOG_LINKS field
Ling-hua Tseng wrote: > Should I write a violent algorithm to scan these data dependencies? > Are there any better solutions for this problem? Another example to look at might be the ia64 port. It reruns flow and sched during the machine dependent reorg pass, so we can get the dependencies right. However, ia64 is the only port that does this, and this is a bit complicated to get right. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: a question about code instrumentation in RTL level
sean yang wrote:
The GCC internals explicitly introduced code manipulation APIs in TREE
representation (bsi_insert_before, bsi_remove etc). But I did not see
the equivalent for RTL representation.
There is emit_insn_after, emit_insn_before.
There is also the sequence stuff: start_sequence, end_sequence,
push_to_sequence, etc. This allows you to emit multiple insns into a
sequence, which can then be passed to emit_insn_{after,before}.
Try looking at the function definitions in emit-rtl.c, and various code
that uses them.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: config/gnu.h, config/i386/gnu.h don't include copyright notices
On Jul 17, 2006, at 3:43 PM, Jim Wilson wrote: Also, sometimes it happens that a file will start as trivial/non- trivial, and then later modifications will change it to non-trivial/ trivial, but the patcher doesn't bother to add/remove the copyright notice. Just like sometimes people forget to change the date in the copyright notice. Just be careful to not so fix any file included by a file with the libgcc style copyright. :-( Once fixed, we can't generally assume we can unfix it.
Inserting a GIMPLE node in a SSA form representation pass
I'd like to ask a question about difference of SSA-form representation and
GIMPLE representation. I thanks you for your answer.
My understanding is that any stmt node insertion operation in a pass between
building-SSA pass and un-SSA pass should uses SSA-form representation. But
the following function (schedule_sm() in tree-ssa-loop-im.c in GCC4.0.2)
inserts a stmt node " store = build (MODIFY_EXPR, void_type_node,
unshare_expr (ref), tmp_var);" with a regular GIMPLE representation. So my
question is: nder what situation, GIMPLE node and SSA-form node is same.
Specifically, is a CALL_INSN stmt under these two TREE IR same? i.e.,
inserting a CALL_INSN (to do some intrumentation statistics) with GIMPLE
form would not cause error?
Can someone give a brief introduction? Hopefully my question is clear:)
Thanks again,
Sean
static void
schedule_sm (struct loop *loop, edge *exits, unsigned n_exits, tree ref,
struct mem_ref *mem_refs)
{
struct mem_ref *aref;
tree tmp_var;
unsigned i;
tree load, store;
struct fmt_data fmt_data;
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file, "Executing store motion of ");
print_generic_expr (dump_file, ref, 0);
fprintf (dump_file, " from loop %d\n", loop->num);
}
tmp_var = make_rename_temp (TREE_TYPE (ref), "lsm_tmp");
fmt_data.loop = loop;
fmt_data.orig_loop = loop;
for_each_index (&ref, force_move_till, &fmt_data);
rewrite_mem_refs (tmp_var, mem_refs);
for (aref = mem_refs; aref; aref = aref->next)
if (LIM_DATA (aref->stmt))
LIM_DATA (aref->stmt)->sm_done = true;
/* Emit the load & stores. */
load = build (MODIFY_EXPR, void_type_node, tmp_var, ref);
get_stmt_ann (load)->common.aux = xcalloc (1, sizeof (struct
lim_aux_data));
LIM_DATA (load)->max_loop = loop;
LIM_DATA (load)->tgt_loop = loop;
/* Put this into the latch, so that we are sure it will be processed after
all dependencies. */
bsi_insert_on_edge (loop_latch_edge (loop), load);
for (i = 0; i < n_exits; i++)
{
store = build (MODIFY_EXPR, void_type_node,
unshare_expr (ref), tmp_var);
bsi_insert_on_edge (exits[i], store);
}
}
_
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
