Re: More __comp_ctor () woes
I have been looking at the source in class.c: clone_function_decl() clone_constructors_and_destructors() pt.c: check_explicit_specialization() In pt.c: check_explicit_specialization() it specifically requests that the clone function of a specialised constructor NOT add the new clone to the classes method vector. Does this have something to do with the comment in the code in that by not adding a method to the types method vector it somehow defines the constructor as being "not in charge"? I thought that an "in charge" or not "in charge" constructor was defined using some other means than by wether or not the constructor is in the types method vector. I can now go ahead and hook into the clone method to gather the information i need, however it is a bit hackish and I am still trying to understand why the specialisation of a template constructor does not get added to the methods vector. Thanks for any information in advance. Brendon. The appropiate few lines of code in the pt.c: check_explicit_specialization() file look as shown below: else if (DECL_CONSTRUCTOR_P (decl) || DECL_DESTRUCTOR_P (decl)) /* This is indeed a specialization. In case of constructors and destructors, we need in-charge and not-in-charge versions in V3 ABI. */ clone_function_decl (decl, /*update_method_vec_p=*/0); /* Register this specialization so that we can find it again. */ decl = register_specialization (decl, gen_tmpl, targs);
Re: LOOP_HEADER tree code?
Zdenek Dvorak <[EMAIL PROTECTED]> writes: > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > introducing a tree LOOP_HEADER with single argument N (number of > iterations of the loop), that would be present in IL at the beginning of > header of each loop. I have following motivations: > > 1) One of the goals of the project is to avoid recomputing number of >iterations of loops, and to keep this information (analysing # of >iterations is fairly expensive, and we recompute this information >quite a lot at the moment). To keep the information valid, we need >to prevent optimizations from destroying it (e.g., if the number >is n_1 = n_2 - 1, and this is the last use of n_1, we do not want >DCE to remove it); this is easy to achieve if n_1 would be the >argument of LOOP_HEADER. Without this tree node in IL, we would need >to handle this specially in DCE, and possibly also other optimizers. > 2) This statement might make it simpler to ensure that various >optimizers update the loops correctly. > > I am not quite sure whether this is a good idea, though. Are there some > reasons why not to do this, or any other problems with the idea? I haven't seen anyone else say this, but this sounds worryingly like the old RTL loop notes to me. I'm sure the loop notes seemed like a good idea when they were first introduced (probably for similar reasons) but they became such a bug-bear in the end. Not a very constructive comment, I'll be the first to admit. Richard
Re: Abt -fpic, -fPIC Option
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > "Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > >> I have built a cross-compiler for m68k-elf with GCC 4.1.1. >> I need to know the difference in implementations of -fpic and -fPIC >> for this particular target. > > -fpic uses a 16-bit offset when accessing the GOT. -fPIC uses a > 32-bit offset. Thus -fpic may fail if you have more than 16K global > variables. and -fPIC will fail on the 68000 (are there still 68000s > out there?). FWIW, Coldfire targets, like the 68000, are also restricted to 16-bit offsets. Richard
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Roger Sayle writes: > > Hi David, > > On Sun, 22 Oct 2006, David Daney wrote: > > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]> > > David Daney <[EMAIL PROTECTED]> > > > > PR middle-end/29519 > > * rtlanal.c (nonzero_address_p): Remove check for values wrapping. > > :REVIEWMAIL: > > This is ugly. I agree with you and Richard that this optimization > isn't safe unless we can somehow prevent the RTL optimizers from > creating the problematic RTL that they currently do. But I also > worry how much benefit some platforms get from the current unsafe > transformation, and whether there'd be an observable performance > degradation with this fix. > > I think its best to apply this patch to mainline to allow the > benchmarking folks test whether there's any change. Likewise if > someone could check whether there are any/many code generation > differences in cc1 files (or similar), that'd go some way to > silencing my potential concerns. > > Only after this has been on mainline for a while without problems > or performance issues, should we consider backporting it to the 4.2 > branch. > > Does this sound reasonable? I must admit to being a little perplexed by this. We have an unsafe optimization that causes bad code to be generated on at least one platform. However, we want to continue to perform this unsafe optimization on our release branch until we are sure that removing it doesn't cause performance regressions. And, perhaps, if removing the optimization does cause performance regressions we won't remove it, preferring bad code to reduced performance. Is that a fair summary? Perhaps I'm misunderstanding what you wrote. Andrew.
Re: LOOP_HEADER tree code?
> > quite a lot at the moment). To keep the information valid, we need > > to prevent optimizations from destroying it (e.g., if the number > > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > > DCE to remove it); this is easy to achieve if n_1 would be the > > argument of LOOP_HEADER. You are proposing to complete the ssa representation such that foreach_ssa_uses also iterates over the niter information (a bit like vrp modifies the ssa chains with its extra assert information). Wouldn't it be possible to not insert this niter information in the representation of the program (ie. not inserting a new tree node) but just modify the ssa iterators to also return the expressions that we store on the side? > > Without this tree node in IL, we would need > > to handle this specially in DCE, and possibly also other optimizers. What are the other transformations that remove definitions that are not used? > >2) This statement might make it simpler to ensure that various > > optimizers update the loops correctly. > > > >I am not quite sure whether this is a good idea, though. Are there some > >reasons why not to do this, or any other problems with the idea? > > > > Why not keeping this information outside the IL I am not sure what you mean by that? Just keeping the niter info in the loop structure, and not inserting a new node in the IL for storing the niter.
Re: LOOP_HEADER tree code?
Hello, > >> > quite a lot at the moment). To keep the information valid, we need > >> > to prevent optimizations from destroying it (e.g., if the number > >> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > >> > DCE to remove it); this is easy to achieve if n_1 would be the > >> > argument of LOOP_HEADER. > > You are proposing to complete the ssa representation such that > foreach_ssa_uses also iterates over the niter information (a bit like vrp > modifies the ssa chains with its extra assert information). Wouldn't it > be possible to not insert this niter information in the representation of > the > program (ie. not inserting a new tree node) but just modify the ssa > iterators > to also return the expressions that we store on the side? yes, it would be possible, however, possibly quite error-prone. > >> > Without this tree node in IL, we would need > >> > to handle this specially in DCE, and possibly also other optimizers. > > What are the other transformations that remove definitions that are not > used? ivopts remove bivs that they replace, and I suspect that vectorizer does something similar as well. I do not know about other optimizers. Zdenek
Re: LOOP_HEADER tree code?
> You are proposing to complete the ssa representation such that > foreach_ssa_uses also iterates over the niter information (a bit like vrp > modifies the ssa chains with its extra assert information). Wouldn't it > be possible to not insert this niter information in the representation of > the > program (ie. not inserting a new tree node) but just modify the ssa > iterators > to also return the expressions that we store on the side? yes, it would be possible, however, possibly quite error-prone. > What are the other transformations that remove definitions that are not > used? ivopts remove bivs that they replace, and I suspect that vectorizer does something similar as well. I do not know about other optimizers. The scev info has the same problem as the niter info, as we store it on the side, making it vulnerable to any code transform. Now if we modify the var renaming, removal, ... aware of the information that we store on the side, we could avoid all these rather costly re-computations.
Re: LOOP_HEADER tree code?
Hello, > >> You are proposing to complete the ssa representation such that > >> foreach_ssa_uses also iterates over the niter information (a bit like vrp > >> modifies the ssa chains with its extra assert information). Wouldn't it > >> be possible to not insert this niter information in the representation of > >> the > >> program (ie. not inserting a new tree node) but just modify the ssa > >> iterators > >> to also return the expressions that we store on the side? > > > >yes, it would be possible, however, possibly quite error-prone. > > > >> What are the other transformations that remove definitions that are not > >> used? > > > >ivopts remove bivs that they replace, and I suspect that vectorizer > >does something similar as well. I do not know about other optimizers. > > > > The scev info has the same problem as the niter info, as we store it on > the side, making it vulnerable to any code transform. Now if we modify > the var renaming, removal, ... aware of the information that we store > on the side, we could avoid all these rather costly re-computations. I did that once. Updating scev info turned out to be more expensive than recomputing it. Zdenek
fdump-tree explanation
Hi all, i want to make a statistic(i haven't found one) over linux source code, and i want to know how many times expressions are simplified by gcc. I've found that "-O -ftree-dominator-opts -fdump-tree-optimized" writes a file optimized, now if i can compare it with a not optimized one i win, "unfortunally" there are a lot of options for tree dumping, witch one shoud i use? tnx, Dino
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Andrew Haley wrote: Roger Sayle writes: > > Hi David, > > On Sun, 22 Oct 2006, David Daney wrote: > > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]> > > David Daney <[EMAIL PROTECTED]> > > > > PR middle-end/29519 > > * rtlanal.c (nonzero_address_p): Remove check for values wrapping. > > :REVIEWMAIL: > > This is ugly. I agree with you and Richard that this optimization > isn't safe unless we can somehow prevent the RTL optimizers from > creating the problematic RTL that they currently do. But I also > worry how much benefit some platforms get from the current unsafe > transformation, and whether there'd be an observable performance > degradation with this fix. > > I think its best to apply this patch to mainline to allow the > benchmarking folks test whether there's any change. Likewise if > someone could check whether there are any/many code generation > differences in cc1 files (or similar), that'd go some way to > silencing my potential concerns. > > Only after this has been on mainline for a while without problems > or performance issues, should we consider backporting it to the 4.2 > branch. > > Does this sound reasonable? I must admit to being a little perplexed by this. We have an unsafe optimization that causes bad code to be generated on at least one platform. However, we want to continue to perform this unsafe optimization on our release branch until we are sure that removing it doesn't cause performance regressions. And, perhaps, if removing the optimization does cause performance regressions we won't remove it, preferring bad code to reduced performance. Is that a fair summary? Perhaps I'm misunderstanding what you wrote. That would be one interpretation. I prefer: We have an unsafe optimization that causes bad code to be generated on at least one platform. One potential fix may cause performance regressions, so we will test it on the mainline for a while to see if there are any unexpectedly bad side effects. If there are none, we will commit it to 4.2 also, if there are we may try a different fix. David Daney
Maintainer(s) for loop optimizer(s)
Hello, at the moment, RTL level loop optimizers and most of the tree-level loop optimizers do not have assigned specific maintainers. I think this clearly starts to become a significant problem -- many of the loop-optimizer related patches in 4.2 timeframe remained unreviewed (the vectorizer improvement changes, some of my patches for ivopts cleanup, etc.). In 4.3 and 4.4 timeframe, there are several projects related to loop optimizations (http://gcc.gnu.org/wiki/AutovectBranchOptimizations, http://gcc.gnu.org/wiki/PredictiveCommoning, http://gcc.gnu.org/wiki/AutomaticParallelization, http://gcc.gnu.org/wiki/PrefetchingImprovements, http://gcc.gnu.org/wiki/PreservingLoops, Graphite), that I fear might face delays because of the same problem (see e.g. the (lack of) results of my attempt to find reviewers for some of them, http://gcc.gnu.org/ml/gcc/2006-09/msg00477.html). And, of course, there are other situations where the fact that there is no official maintainer is a problem (when looking for someone able to fix a bug in one of the optimizers, or if someone has questions regarding them). On gcc summit, I discussed this with several active loop optimization developers (Daniel Berlin, Sebastian Pop), and we agreed that one possible solution would be to have myself and Daniel Berlin to co-maintain the loop optimizers. This was proposed to the steering committee several months ago; however, since there was no progress in the meantime, I assume this proposal was rejected. Therefore, I would like to ask steering committee to propose an alternative solution. There does not seem to be any easy way how to address a mail just to the steering committee, so I am sending this to the gcc mailing list in hope that it will reach the right recipients. Zdenek
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Hi Andrew, On Wed, 25 Oct 2006, Andrew Haley wrote: > I must admit to being a little perplexed by this. > > We have an unsafe optimization that causes bad code to be generated on > at least one platform. However, we want to continue to perform this > unsafe optimization on our release branch until we are sure that > removing it doesn't cause performance regressions. And, perhaps, if > removing the optimization does cause performance regressions we won't > remove it, preferring bad code to reduced performance. > > Is that a fair summary? Perhaps I'm misunderstanding what you wrote. The issue is that there are two possible fixes to this problem... This wrong code regression was introduced by the recent bug-fix patch to address an aspect of PR middle-end/28690, a missed optimization regression affecting gcc 4.2 and 4.3. That change then exposed a latent bug in the RTL optimizers that has been there 2002. The ultra-conservative approach would be to simply back-out the patch that exposed the bug, and simply accept the performance degradation. The alternative is to progress towards "our ideal world" by actually fixing the problem rather than working around the issue. Unfortunately, moving forward is itself not without risk, both to the tree's stability and to the performance impact of removing an optimization that's been there for years. The fixes trade-off one performance issue against the possibility of another. In my professional judgement as a middle-end maintainer, the appropriate course is to move mainline forward to better evaluate the risks and tradeoffs of the proposed changes. Then depending upon the outcome, decide which of the two solutions should be backported to the release branches. Given the expected release timings, it makes sense to avoid "acting in haste" and to make the right decision. If we're in a rush, I'd push for reverting the PR28690 from the release branch and return us to a known state, and accept the performance loss. But if Richard Sandiford's and David Daney's patch works out, we can correct the wrong-code issue, without the performance loss. Once explained, I'd expect most maintainers would make precisely the same call? Roger --
Re: fdump-tree explanation
"Dino Puller" <[EMAIL PROTECTED]> writes: > i want to make a statistic(i haven't found one) over linux source > code, and i want to know how many times expressions are simplified by > gcc. I don't think any of us know what you mean by "how many times expressions are simplified." Can you be more specific? Can you provide an example of what you want to look for, and an example of what you do not want to look for? Ian
Re: LOOP_HEADER tree code?
Hello, for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering introducing a tree LOOP_HEADER with single argument N (number of iterations of the loop), that would be present in IL at the beginning of header of each loop. I have following motivations: 1) One of the goals of the project is to avoid recomputing number of iterations of loops, and to keep this information (analysing # of iterations is fairly expensive, and we recompute this information quite a lot at the moment). To keep the information valid, we need to prevent optimizations from destroying it (e.g., if the number is n_1 = n_2 - 1, and this is the last use of n_1, we do not want DCE to remove it); this is easy to achieve if n_1 would be the argument of LOOP_HEADER. Without this tree node in IL, we would need to handle this specially in DCE, and possibly also other optimizers. 2) This statement might make it simpler to ensure that various optimizers update the loops correctly. However, various optimizer needs to know about this special tree node. Or am I missing something? I am not quite sure whether this is a good idea, though. Are there some reasons why not to do this, or any other problems with the idea? Zdenek - Devang
Re: LOOP_HEADER tree code?
On Wed, 2006-10-25 at 10:31 -0700, Devang Patel wrote: > > Hello, > > > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > > introducing a tree LOOP_HEADER with single argument N (number of > > iterations of the loop), that would be present in IL at the beginning of > > header of each loop. I have following motivations: > > > >1) One of the goals of the project is to avoid recomputing number of > > iterations of loops, and to keep this information (analysing # of > > iterations is fairly expensive, and we recompute this information > > quite a lot at the moment). To keep the information valid, we need > > to prevent optimizations from destroying it (e.g., if the number > > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > > DCE to remove it); this is easy to achieve if n_1 would be the > > argument of LOOP_HEADER. Without this tree node in IL, we would need > > to handle this specially in DCE, and possibly also other optimizers. > >2) This statement might make it simpler to ensure that various > > optimizers update the loops correctly. > > However, various optimizer needs to know about this special tree node. > Or am I missing something? Correct. Take for example jump threading -- it can peel off a loop iteration which would invalidate the LOOP_HEADER node. That seems like a recipe for disaster. Code motion passes would have to be aware of this special node as well. And we've seen how well that works in the RTL backend with its loop notes -- it was a major PITA. I'd rather not repeat the mistakes we've already made. Jeff
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Roger Sayle <[EMAIL PROTECTED]> writes: > Once explained, I'd expect most maintainers would make precisely the > same call? I suppose the counter-argument is that we shouldn't ship 4.2 in its current state. We should either back out the patch that made REG_POINTER more prominent or go with the fix for this PR. From that point of view, there doesn't seem to be much advantage in keeping the 4.2 branch in its current state. Lots of people seem to test release branches -- probably more than mainline -- and I would hope that using the fix from this PR is by far the strongest contender. I think we'd be doing ourselves a favour by going with what we expect to be the final fix and getting as much testing of it as possible. After all, it's not difficult to test & apply a patch to a branch at the same time as mainline, or to revert it in the same way. Also, having patches on mainline and not a release branch can cause quite a bit of confusion. Witness what happend with PR 28243, where I fixed something on mainline, but it was not directly approved for a release branch. Then Eric B. worked around the same problem on the release branch and forward-ported the work-around to mainline, where it wasn't really needed. (It's quite common for a testcase to only fail on a release branch, and pass on mainline due to unrelated code generation changes, so there was no reason for Eric to be suspicious.) I just don't think it's as obvious a call as your question above makes out. There are downsides to this approach too, especially when no one person is in overall charge of repository (mainline and branch). Richard
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
> Lots of people seem to test release branches -- probably more than mainline > -- and I would hope that using the fix from this PR is by far the strongest > contender. Definitely. People report bugs against released versions and expect fixes for these versions, not for versions that will be released one year from now. > I think we'd be doing ourselves a favour by going with what we > expect to be the final fix and getting as much testing of it as possible. > After all, it's not difficult to test & apply a patch to a branch at the > same time as mainline, or to revert it in the same way. Exactly my position. :-) > Also, having patches on mainline and not a release branch can cause > quite a bit of confusion. Witness what happend with PR 28243, where I > fixed something on mainline, but it was not directly approved for a > release branch. Then Eric B. worked around the same problem on the > release branch and forward-ported the work-around to mainline, where > it wasn't really needed. I'd have said: "fixed a subcase" but the picture is globally correct. Btw, what about backporting your fix? Or is it too late now? > I just don't think it's as obvious a call as your question above makes out. > There are downsides to this approach too, especially when no one person > is in overall charge of repository (mainline and branch). Right. And, in my opinion, these downsides are easily underestimated. -- Eric Botcazou
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Eric Botcazou <[EMAIL PROTECTED]> writes: >> Also, having patches on mainline and not a release branch can cause >> quite a bit of confusion. Witness what happend with PR 28243, where I >> fixed something on mainline, but it was not directly approved for a >> release branch. Then Eric B. worked around the same problem on the >> release branch and forward-ported the work-around to mainline, where >> it wasn't really needed. > > I'd have said: "fixed a subcase" but the picture is globally correct. Yes, I chose my words very badly there, sorry. I wasn't trying to belittle your fix. Richard
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Eric Botcazou wrote: Lots of people seem to test release branches -- probably more than mainline -- and I would hope that using the fix from this PR is by far the strongest contender. Definitely. People report bugs against released versions and expect fixes for these versions, not for versions that will be released one year from now. I think we'd be doing ourselves a favour by going with what we expect to be the final fix and getting as much testing of it as possible. After all, it's not difficult to test & apply a patch to a branch at the same time as mainline, or to revert it in the same way. Exactly my position. :-) Also, having patches on mainline and not a release branch can cause quite a bit of confusion. Witness what happend with PR 28243, where I fixed something on mainline, but it was not directly approved for a release branch. Then Eric B. worked around the same problem on the release branch and forward-ported the work-around to mainline, where it wasn't really needed. I'd have said: "fixed a subcase" but the picture is globally correct. Btw, what about backporting your fix? Or is it too late now? The patch is fully tested and ready to go for the 4.2 branch. Roger is the maintainer of the relevant parts of the compiler. When and if he approves it, I will gladly commit the patch to the branch. David Daney
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
David Daney wrote: Eric Botcazou wrote: Lots of people seem to test release branches -- probably more than mainline -- and I would hope that using the fix from this PR is by far the strongest contender. Definitely. People report bugs against released versions and expect fixes for these versions, not for versions that will be released one year from now. I think we'd be doing ourselves a favour by going with what we expect to be the final fix and getting as much testing of it as possible. After all, it's not difficult to test & apply a patch to a branch at the same time as mainline, or to revert it in the same way. Exactly my position. :-) Also, having patches on mainline and not a release branch can cause quite a bit of confusion. Witness what happend with PR 28243, where I fixed something on mainline, but it was not directly approved for a release branch. Then Eric B. worked around the same problem on the release branch and forward-ported the work-around to mainline, where it wasn't really needed. I'd have said: "fixed a subcase" but the picture is globally correct. Btw, what about backporting your fix? Or is it too late now? The patch is fully tested and ready to go for the 4.2 branch. Most likely you were refering to your patch, and not mine. I should have realized that before sending. But my statements do hold for the PR29519 patch. Roger is the maintainer of the relevant parts of the compiler. When and if he approves it, I will gladly commit the patch to the branch. David Daney
Re: LOOP_HEADER tree code?
Hello, > >for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > >introducing a tree LOOP_HEADER with single argument N (number of > >iterations of the loop), that would be present in IL at the beginning of > >header of each loop. I have following motivations: > > > >1) One of the goals of the project is to avoid recomputing number of > > iterations of loops, and to keep this information (analysing # of > > iterations is fairly expensive, and we recompute this information > > quite a lot at the moment). To keep the information valid, we need > > to prevent optimizations from destroying it (e.g., if the number > > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > > DCE to remove it); this is easy to achieve if n_1 would be the > > argument of LOOP_HEADER. Without this tree node in IL, we would need > > to handle this specially in DCE, and possibly also other optimizers. > >2) This statement might make it simpler to ensure that various > > optimizers update the loops correctly. > > However, various optimizer needs to know about this special tree node. not really (not any more than they know about other tree codes that are not interesting for them). Zdenek > Or am I missing something? > > > > >I am not quite sure whether this is a good idea, though. Are there some > >reasons why not to do this, or any other problems with the idea? > > > >Zdenek > > > - > Devang
Re: LOOP_HEADER tree code?
Hello, > > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > > > introducing a tree LOOP_HEADER with single argument N (number of > > > iterations of the loop), that would be present in IL at the beginning of > > > header of each loop. I have following motivations: > > > > > >1) One of the goals of the project is to avoid recomputing number of > > > iterations of loops, and to keep this information (analysing # of > > > iterations is fairly expensive, and we recompute this information > > > quite a lot at the moment). To keep the information valid, we need > > > to prevent optimizations from destroying it (e.g., if the number > > > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > > > DCE to remove it); this is easy to achieve if n_1 would be the > > > argument of LOOP_HEADER. Without this tree node in IL, we would need > > > to handle this specially in DCE, and possibly also other optimizers. > > >2) This statement might make it simpler to ensure that various > > > optimizers update the loops correctly. > > > > However, various optimizer needs to know about this special tree node. > > Or am I missing something? > Correct. Take for example jump threading -- it can peel off a loop > iteration which would invalidate the LOOP_HEADER node. of course, if it does that, it must update the information at the loop (regardless of whether we use the LOOP_HEADER node for it, or not). > That seems > like a recipe for disaster. No, that seems like a good way how to detect that jump threading is doing something it should not, or forgetting to update something in the progress. > Code motion passes would have to be aware of this special node as well. > And we've seen how well that works in the RTL backend with its loop > notes -- it was a major PITA. The problem was that loop notes was something special, different from other RTL statements. Of course, we can live without LOOP_HEADER tree node; however, that means that more optimizers will have to be aware of information stored in loop structures, which looks more like the case with the loop notes to me. Zdenek > I'd rather not repeat the mistakes we've already made. > > Jeff >
A public discussion group for IA32 psABI
On Tue, Oct 10, 2006 at 11:21:41AM -0500, Menezes, Evandro wrote: > > H.J., do you have the i386 psABI in source form somewhere I could get > > it, to make the corresponding changes? > > Actually, it's about an extension to the i386 psABI and it's an idea still in > its infancy: http://sourceware.org/ml/binutils/2006-09/msg00342.html. > Some people told that FSG might not be the best place to start the public IA32 psABI discussion group. I created one at http://groups-beta.google.com/group/ia32-abi We can reconsider if it should be moved to FSG later. Alexandre, could you please upload your IA32 psABI extension proposal to it? Thanks. H.J.
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
On Wed, 25 Oct 2006, Richard Sandiford wrote: > Roger Sayle <[EMAIL PROTECTED]> writes: > > Once explained, I'd expect most maintainers would make precisely the > > same call? > > I suppose the counter-argument is that we shouldn't ship 4.2 in its > current state. We should either back out the patch that made > REG_POINTER more prominent or go with the fix for this PR. I repeat that its not an issue of does it get fixed or not, but of which is the more suitable fix. I think it's very safe to assume that we have at least a few days to evaluate our options on mainline rather than make a rush decision. With 108 serious regressions including 12 P1s, of course we shouldn't ship 4.2 in its current state. We've not yet had a release candidate, or timeline for release. I've absolutely no intention of not selecting which fix to backport to the release branch long before the release's due date. My counter-counter argument would be that it's the rush to backport changes to the release branch that has caused this problem. If the PR 28690 fix had had longer on mainline, such that we'd identified its side-effect of breaking libgcj on MIPS, it wouldn't have been applied to the branch before we'd fully understood which other changes are also required. The 28690 fix was fully tested on IA-32 and PowerPC and there was no fault in applying that fix; it's fallout was unforeseeable. There's also no fault on the MIPS maintainers and testers for not identifying the issue earlier. Indeed, you came up with a corrective fix very quickly. But once again, this change is not 100% safe (very few changes to the compiler ever are). There is a very real possibility that disabling this optimization could have a significant performance impact on non-MIPS platforms. Indeed, that David's seen a large number of code generation differences means that I'd like to get a better handle of its effects on benchmarking. Perhaps we should discuss this further on IRC, or open up the thread to general discussion and comment. Back when I first started contributing to GCC, it was not uncommon to be expected to bootstrap RTL patches on five or six targets, including simulators and to present SPEC figures. Several of my large changes took many months to get approved, and for all that the statistics on how frequently mainline bootstrap was broken were abysmal. Even with any amount of contributor and reviewer testing, it's inevitable that bugs slip through. The huge size of software engineering projects such as GCC means that the combinatorial number of interactions between different components means that its impossible for an individual or any goup of maintainers to predict how they'll play with each other. My belief/position is that rather than become paralysed by this complexity, the work-flow needs to be adapted to accomodate for it. One of the contributing factors for the egcs-FSF split was poor reviewer response time. Hence, my vote is to be more accepting and lenient of patches, instead relying on the power of GCC's community to support patch validation. Very few contributors have access to MIPS hardware, or alpha hardware, or SPEC, or nullstone, etc... but our project benefits from the fact that one of the major "unseen" contributions is that folks regularly contribute their time to build, test and benchmark. The open-source principle that "given sufficient eyes all bugs are shallow". Rather than be (what I consider) unreasonable and require that David run SPEC on at least both PowerPC and IA-32 to verify there's no slow-down or quantify how severe it is, I have the option to provisionally approve patches for mainline, and then look at Deigo's, Andreas's and Richi's automatic benchmarking, and the results of the autotesters. I honestly would like to have the ability to look at a patch and say with 100% confidence and certainty, and without reservation that it should be applied to the 4.0 branch. However, waiting 48 or 72 hours to obtain more feedback not only "covers my arse", but should be common sense and "best practice". Now I completely agree that there is a real downside to this approach. The strategy leads to the additional complexity of large numbers of patches in flight, applied to different branches and in different orders. Fortunately for us, we have excellent engineering practices in place to keep track of this. Bugzilla (and the bug masters) continually maintains an up to date list of which bugs are present on which branches. A release manager can instantly see which bugs still affect an upcoming release, *and* see that they may have been fixed on mainline. It's also no additional overhead to the contributor. Our rules for applying patches to the branches require that each patch must be tested against the branch to which it is to be applied. Even without the complexity of pending fixes waiting to be backported, there's always a significant divergence between branches that requires retesting that changes a
Re: Re: LOOP_HEADER tree code?
> However, various optimizer needs to know about this special tree node. not really (not any more than they know about other tree codes that are not interesting for them). If we take an example of Jump Threading pass then it needs to know about this tree node and update it properly. So, the passes that maniuplate loop structure need to know about LOOP_HEADER and others do not need to worry about LOOP_HEADER. Now, focusing on the passes that manipulate loop structure. Are these pass responsible for fixing loop info or is it responsiblity of cleanup pass ? - Devang
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
On Wed, 25 Oct 2006, David Daney wrote: > The patch is fully tested and ready to go for the 4.2 branch. The last thing I want is for this fix to get delayed whilst we argue over patch testing/approval policy. This fix addresses the known wrong-code issue, and at worst may replace it with missed optimization opportunity. Hence although we don't know for sure whether this is better than reverting the patch that caused the regression, it's certainly better than where 4.2 is now, and keeps us sync'd with mainline. Ok for the 4.2 branch. Sorry for the confusion. Hopefully, there'll be no more surprises. Roger --
Re: Re: LOOP_HEADER tree code?
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> wrote: > > However, various optimizer needs to know about this special tree node. > > not really (not any more than they know about other tree codes that are > not interesting for them). If we take an example of Jump Threading pass then it needs to know about this tree node and update it properly. Yes, when it modifies the CFG in ways that affect the loops info. And one nice thing about this LOOP_HEADER idea is that, in your example, Jump Threading: - can see that node so it knows there is something to update - knows what it is changing so it also knows how that affects the loops info - can change it on-the-fly This means, no need for a cleanup pass after all changes are done. So, the passes that maniuplate loop structure need to know about LOOP_HEADER and others do not need to worry about LOOP_HEADER. More acurately, the passes that manipulate the cfg. Right now most of these passes don't even know they modify the loop structure. Now, focusing on the passes that manipulate loop structure. Are these pass responsible for fixing loop info or is it responsiblity of cleanup pass ? It seems to me that a cleanup pass would defeat the purpose of keeping loop info up to date. Your cleanup pass would probably end up just recomputing everything. That said, I don't really see what a LOOP_HEADER node would give you that you can't get by making the cfg-modifying passes actually loop-aware, or perhaps by using cfghooks to update the loop information on the fly when a pass changes the CFG. It would be helpful if Zdenek could give an example where a LOOP_HEADER node is really the only way to help keep loop info accurate. Gr. Steven
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
> Finally before I finish the retrospective part of this e-mail, I'll > point out this isn't a sudden recent unilateral policy decision, but > purely a crystallization of the prescribed GCC work-flow outlined in > contributing.html that has been refined over many years. I disagree. I've been working on GCC for almost 5 years and you're the only maintainer who has ever requested me to wait before backporting a fix for a regression on a release branch. That may be hard to believe, but I honestly think that I'm not rewriting history here. > As a reviewer I have more comfort and faith in patches that have had more > testing than those that haven't. Given that different branches have > differing stability/certainty requirements, it makes sense that its easier > to get a patch approached for mainline and/or 4.3, than it is for 4.1, > 4.0 or 3.4. In my opinion, it is (almost) always possible to make a judgment a priori. > The obvious question is what can be done to learn from and prevent > repeating the problems of the past. I'd suggest that absolutely no-one > could have forseen that the PR28690 would have adversely affected > MIPS/libgcj. Well, REG_POINTER is a tricky business as HP-UX maintainers can tell you. However, we don't have to hold ourselves to an unrealistic standard; there will always be unexpected interactions, that's OK I'd think. > I'm not sure that applying it immediately to the release branches would > improve things. Likewise, for David's current fix, we know it'll affect > primary platforms that haven't been tested, we just don't know how. So why not give the patch more exposure by putting it on the active release branch sooner than later? > I think one source of the problem is that standards the that I hold > myself to, may potentially be unrealistic for many contributors. Definitely. I'd say that the patches you review are not your babies, only those you write are. :-) -- Eric Botcazou
Re: Re: LOOP_HEADER tree code?
Hello, > >So, the passes that maniuplate loop structure need to know about > >LOOP_HEADER and others do not need to worry about LOOP_HEADER. > > More acurately, the passes that manipulate the cfg. Right now most of > these passes don't even know they modify the loop structure. > > >Now, focusing on the passes that manipulate loop structure. Are these > >pass responsible for fixing loop info or is it responsiblity of cleanup > >pass ? > > It seems to me that a cleanup pass would defeat the purpose of keeping > loop info up to date. Your cleanup pass would probably end up just > recomputing everything. > > That said, I don't really see what a LOOP_HEADER node would give you > that you can't get by making the cfg-modifying passes actually > loop-aware, or perhaps by using cfghooks to update the loop > information on the fly when a pass changes the CFG. It would be > helpful if Zdenek could give an example where a LOOP_HEADER node is > really the only way to help keep loop info accurate. it definitely is not the only way, and seeing the reaction of people, I probably won't use it. The main reason for considering to use the tree node for me was the possibility to make the number of iterations of the loop as its operand, so that I would not need to worry about keeping it alive through dce, copy/constant propagation, etc. (without a statement carrying it in IL, I do not see a solution that would not be just asking for introducing bugs and getting broken accidentally). Zdenek
Re: Re: Re: LOOP_HEADER tree code?
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, > >So, the passes that maniuplate loop structure need to know about > >LOOP_HEADER and others do not need to worry about LOOP_HEADER. > > More acurately, the passes that manipulate the cfg. Right now most of > these passes don't even know they modify the loop structure. > > >Now, focusing on the passes that manipulate loop structure. Are these > >pass responsible for fixing loop info or is it responsiblity of cleanup > >pass ? > > It seems to me that a cleanup pass would defeat the purpose of keeping > loop info up to date. Your cleanup pass would probably end up just > recomputing everything. > > That said, I don't really see what a LOOP_HEADER node would give you > that you can't get by making the cfg-modifying passes actually > loop-aware, or perhaps by using cfghooks to update the loop > information on the fly when a pass changes the CFG. It would be > helpful if Zdenek could give an example where a LOOP_HEADER node is > really the only way to help keep loop info accurate. it definitely is not the only way, I do not know what is the best approach. One expect discipline from passes and other require some way to know what pass did. and seeing the reaction of people, I probably won't use it. The main reason for considering to use the tree node for me was the possibility to make the number of iterations of the loop as its operand, so that I would not need to worry about keeping it alive through dce, copy/constant propagation, etc. (without a statement carrying it in IL, I do not see a solution that would not be just asking for introducing bugs and getting broken accidentally). One way to achieve this is to mark n_1 (in your example) as "do not dead strip because I know it is used" , kind of attribute((used)). - Devang
Re: Re: Re: LOOP_HEADER tree code?
> > > and seeing the reaction of people, > > I probably won't use it. The main reason for considering to use > > the tree node for me was the possibility to make the number of iterations > > of the loop as its operand, so that I would not need to worry about > > keeping it alive through dce, copy/constant propagation, etc. (without > > a statement carrying it in IL, I do not see a solution that would not > > be just asking for introducing bugs and getting broken accidentally). > > One way to achieve this is to mark n_1 (in your example) as > "do not dead strip because I know it is used" , kind of attribute((used)). This is what as I understand LOOP_HEADER is used for. You just make the statement as useful when doing DCE so you don't loose it. Then nothing goes funny and only very few things have to be updated, DCE is one and that is it. -- Pinski
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Eric Botcazou wrote: Finally before I finish the retrospective part of this e-mail, I'll point out this isn't a sudden recent unilateral policy decision, but purely a crystallization of the prescribed GCC work-flow outlined in contributing.html that has been refined over many years. I've reviewed this thread, because there was some discussion about how to handle release branches. In general, I'd prefer that all patches to fix regressions go on the release branch at the same time as they go to mainline. However, I have myself failed to do that at times; I presently have a few C++ patches which need backporting to 4.1, and I have not yet done that. At a minimum, in such a case, there should be a PR open for the release branch failure, and it should note the presence of the patch on mainline. (I've done that for my C++ patches, in that the check-in messages on mainline are in the PRs.) From my perspective, as RM, the critical thing is that we have a PR and a record of the patch, so that as we approach the release we know we have a bug, and we know we have an option available to fix it. I also recognize that there may sometimes be patches that appear risky, and that we therefore want to apply them to mainline before applying them to release branches too. I think that's perfectly appropriate. In other words, I think this is a judgment call, and I think maintainers should be free to make it. But, in general, please do try to put patches on release branches, especially if they fix P1 regressions. Sacrificing code quality for correctness is the right tradeoff for a release branch, if we have to pick, so if a patch is "only" going to pessimize code, it should be a very strong candidate for a release branch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Re: Re: Re: LOOP_HEADER tree code?
On 10/25/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > and seeing the reaction of people, > > I probably won't use it. The main reason for considering to use > > the tree node for me was the possibility to make the number of iterations > > of the loop as its operand, so that I would not need to worry about > > keeping it alive through dce, copy/constant propagation, etc. (without > > a statement carrying it in IL, I do not see a solution that would not > > be just asking for introducing bugs and getting broken accidentally). > > One way to achieve this is to mark n_1 (in your example) as > "do not dead strip because I know it is used" , kind of attribute((used)). This is what as I understand LOOP_HEADER is used for. Big difference. New tree vs TREE_USED or DECL_PRESERVE_P bit. - Devang You just make the statement as useful when doing DCE so you don't loose it. Then nothing goes funny and only very few things have to be updated, DCE is one and that is it. -- Pinski -- - Devang
Re: Re: Re: Re: LOOP_HEADER tree code?
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> wrote: > > One way to achieve this is to mark n_1 (in your example) as > > "do not dead strip because I know it is used" , kind of attribute((used)). > > This is what as I understand LOOP_HEADER is used for. Big difference. New tree vs TREE_USED or DECL_PRESERVE_P bit. DECL_PRESERVE_P wouldn't work, because afaiu the number of iterations is stored in an SSA_NAME tree node , not a *DECL node. You could use TREE_USED, but your suggestion implies that dead code should be retained in the program, just for the sake of knowing how many iterations a loop has. I wouldn't be surprised if some passes are not prepared to handle that, and it sounds like just a really bad idea. Gr. Steven
Re: Re: LOOP_HEADER tree code?
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: it definitely is not the only way, and seeing the reaction of people, I probably won't use it. The main reason for considering to use the tree node for me was the possibility to make the number of iterations of the loop as its operand, so that I would not need to worry about keeping it alive through dce, copy/constant propagation, etc. (without a statement carrying it in IL, I do not see a solution that would not be just asking for introducing bugs and getting broken accidentally). I wouldn't give up so fast. If there are convincing technical reasons for this kind of tree node, then your idea should be seriously considered. Many people thought ASSERT_EXPRs were a really bad idea too, when they were invented... Gr. Steven
Re: Re: Re: Re: Re: LOOP_HEADER tree code?
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: You could use TREE_USED, but your suggestion implies that dead code should be retained in the program, May be I misunderstood, but it is not dead code. Here is what Zdenek said, " ... To keep the information valid, we need > to prevent optimizations from destroying it (e.g., if the number > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > DCE to remove it); ..." - Devang
Re: Re: Re: Re: Re: LOOP_HEADER tree code?
On 10/26/06, Devang Patel <[EMAIL PROTECTED]> wrote: On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: > You could use TREE_USED, but your suggestion implies that dead code > should be retained in the program, May be I misunderstood, but it is not dead code. Here is what Zdenek said, " ... To keep the information valid, we need > > to prevent optimizations from destroying it (e.g., if the number > > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > > DCE to remove it); ..." So you would mark n_1 with TREE_USED, and never let it be removed? What would happen if e.g. the entire loop turns out to be dead code? Or if the loop is rewritten (e.g. vectorized) in a way that changes the number of iterations of the loop? Then the assignment to n_1 would be _really_ dead, but there wouldn't be any way to tell. The nice thing about the LOOP_HEADER node is that it makes these uses of SSA names explicit. Gr. Steven
Re: Re: Re: Re: Re: LOOP_HEADER tree code?
> > On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: > > > You could use TREE_USED, but your suggestion implies that dead code > > should be retained in the program, > > May be I misunderstood, but it is not dead code. Here is what Zdenek said, The question now has come to the following point: Do we want to explict in the IR or have a side table which we use to mark the SSA_NAME as still useful. They both have pros and cons. But I say we want to be as explict in the IR as possible. Thanks, Andrew Pinski PS sorry about my return email address, the machine which I use elm from had crashed and then they cloned it and did not fix up the email address issue.
Re: Re: Re: Re: Re: Re: LOOP_HEADER tree code?
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: So you would mark n_1 with TREE_USED, and never let it be removed? What would happen if e.g. the entire loop turns out to be dead code? Or if the loop is rewritten (e.g. vectorized) in a way that changes the number of iterations of the loop? Then the assignment to n_1 would be _really_ dead, but there wouldn't be any way to tell. When it is really dead, you'll have to remove LOOP_HEADER node anyway. Right ? Why not instead reset the TREE_USED bit and let DCE do its job ? I do not want to drag this discussion further, so I'll stop now. - Devang
Large memory requirements for 4.2 and 4.3
For many years, the default gcc compile options for C code generated by Gambit, the Scheme->C compiler, were very simple (-O1 -fschedule- insns2 -fno-math-errno -fno-trapping-math) and I didn't have problems with gcc's space requirements to compile those files. (I often ran into complexity issues with the algorithms, but people here fixed those over the years. Recently, Marc Feeley used a genetic algorithm to find better compile options for Gambit-generated code; he found that performance increased by about 30% with more aggressive optimizations (but not gcse, yet ;-). With these new options I can't compile necessary Gambit-generated C files on darwin-ppc in 2 GB of space, with or without modulo scheduling. I'm sure that the same thing will happen on other architectures for slightly larger files. I filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29374 that gives an example of gcc requiring inordinate (to my mind) amounts of memory to compile a program. Perhaps someone would like to look at this PR and give some perspective on the space requirements I'm seeing. Brad
Re: Re: Re: Re: Re: Re: LOOP_HEADER tree code?
Hello, > On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: > > > >So you would mark n_1 with TREE_USED, and never let it be removed? > >What would happen if e.g. the entire loop turns out to be dead code? > >Or if the loop is rewritten (e.g. vectorized) in a way that changes > >the number of iterations of the loop? Then the assignment to n_1 would > >be _really_ dead, but there wouldn't be any way to tell. > > When it is really dead, you'll have to remove LOOP_HEADER node > anyway. if the loop becomes unreachable, the LOOP_HEADER statement gets removed like any other statement. If there are some changes to the structure of the loop (the loop is cancelled by some optimizer, or the number of iterations changes), the optimizer is required to update loop structures, and LOOP_HEADER node is removed/updated in the progress. These updates need to be done on very few places (basically only in the routines provided to manipulate the loop structures). What is quite important, it is possible to verify the correctness of the code (from e.g. verify_flow_info), and thus quickly catch any problems. > Right ? Why not instead reset the TREE_USED bit and let DCE do > its job ? Many optimizers would need to be taught to know about TREE_USED (or any other bit you would use for that). We do not have this type of restriction for any other ssa names, so this would be brand new functionality (on the other hand, most optimizers would not need to know anything special about LOOP_HEADER statements). This definitely is not a way I would take if I decide not to use LOOP_HEADER. I would probably add some sort of "implicit" uses placed on some basic blocks (or in loops). It would be a bit more difficult to teach the relevant optimizers to know about these uses, but at least I won't be introducing a new brand of ssa names that behave differently than all the other ssa names. Zdenek
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
Roger Sayle wrote: On Wed, 25 Oct 2006, David Daney wrote: The patch is fully tested and ready to go for the 4.2 branch. The last thing I want is for this fix to get delayed whilst we argue over patch testing/approval policy. This fix addresses the known wrong-code issue, and at worst may replace it with missed optimization opportunity. Hence although we don't know for sure whether this is better than reverting the patch that caused the regression, it's certainly better than where 4.2 is now, and keeps us sync'd with mainline. Ok for the 4.2 branch. Sorry for the confusion. Hopefully, there'll be no more surprises. For better or worse I just committed this patch to the gcc-4_2-branch. David Daney
Re: Re: LOOP_HEADER tree code?
On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote: > > > However, various optimizer needs to know about this special tree node. > > > > not really (not any more than they know about other tree codes that are > > not interesting for them). > > If we take an example of Jump Threading pass then it needs to know > about this tree node and update it properly. That could get awful ugly. > > So, the passes that maniuplate loop structure need to know about > LOOP_HEADER and others do not need to worry about LOOP_HEADER. Passes which do code motions may need to know about it -- they don't need to update its contents, but they may need to be careful about how statements are moved around in the presence of a LOOP_HEADER note. Personally I think this is a bad idea. jeff
Re: Re: Re: Re: Re: Re: Re: LOOP_HEADER tree code?
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Many optimizers would need to be taught to know about TREE_USED (or any other bit you would use for that). We do not have this type of restriction for any other ssa names, so this would be brand new functionality (on the other hand, most optimizers would not need to know anything special about LOOP_HEADER statements). This definitely is not a way I would take if I decide not to use LOOP_HEADER. I would probably add some sort of "implicit" uses placed on some basic blocks (or in loops). It would be a bit more difficult to teach the relevant optimizers to know about these uses, but at least I won't be introducing a new brand of ssa names that behave differently than all the other ssa names. Yes, the idea is to record implict use somehow. I did not realize that tree-ssa DCE does not use TREE_USED or DECL_PRESERVE_P. I am not sure how function marked as attribute((used)) will survive otherwise when IPO DCE is able to see whole program. - Devang
Re: Re: LOOP_HEADER tree code?
Hello, > On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote: > > > > However, various optimizer needs to know about this special tree node. > > > > > > not really (not any more than they know about other tree codes that are > > > not interesting for them). > > > > If we take an example of Jump Threading pass then it needs to know > > about this tree node and update it properly. > That could get awful ugly. actually, that will be trivial once jump threading updates loop properly (I have a patch for that). > > So, the passes that maniuplate loop structure need to know about > > LOOP_HEADER and others do not need to worry about LOOP_HEADER. > Passes which do code motions may need to know about it -- they don't > need to update its contents, but they may need to be careful about > how statements are moved around in the presence of a LOOP_HEADER note. Which is IMHO good, as it will at least ensure that they preserve loops, in case it is really relevant for them -- just now, I do not see how code motion could affect loop structures (unless it changes CFG) -- do you have some concrete example of transformation that might be made more problematic by the existence of LOOP_HEADER node? Zdenek
Re: Re: LOOP_HEADER tree code?
On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote: > actually, that will be trivial once jump threading updates loop properly > (I have a patch for that). I'd like to see that. I recall poking at having threading update things like loop exit points and gave up. The problem is you could thread to a loop exit, which in turn might move the loop exit edge to a new point in the CFG. Furthermore, all the statements dominated by the new loop exit edge are no longer in the loop (when they previously were part of the loop). It's possible these problems could be solved by querying the dominator structures, but IIRC they aren't accurate at this point. Your updates may be simpler/easier since you're updating something different. [ This was a couple years ago, so if I've got details wrong, please forgive me. ] > Which is IMHO good, as it will at least ensure that they preserve loops, > in case it is really relevant for them -- just now, I do not see how > code motion could affect loop structures (unless it changes CFG) -- do > you have some concrete example of transformation that might be made > more problematic by the existence of LOOP_HEADER node? It wasn't a matter of changing the loop structure -- the RTL loop optimizer had 3 or 4 notes IIRC and the location of each note in relation to code labels and other insns was important. Code motion would sometimes place an insn between the note and a label. That in turn caused the loop optimizer to barf. There were also problems with edge splitting doing similar kinds of things. While I don't necessarily forsee you running into the exact same set of problems, experience tells us that you do need to be aware of these kinds of issues and plan appropriately for them. jeff
Re: More __comp_ctor () woes
Hi all,
Well after trying numerous different approaches to find the
FUNCTION_DECL node for a constructor like MyClass::MyClass(int) from a
FUNCTION_DECL node for one of the constructors: MyClass::__comp_ctor
(int) or similar, I have found that there is a VERY simple way to do
this using DECL_CLONED_FUNCTION()
I am posting my understanding here in case others are searching for the
same information in the future.
The __comp_ctor (), __base_ctor (), and similarly __comp_dtor () ...
like functions are created as clones of what i call "user constructors".
I.e. for the code:
class MyClass
{
public:
MyClass(int i) {}
};
GCC will generate:
1) MyClass::__comp_ctor (int)
2) MyClass::__base_ctor (int)
3) MyClass::MyClass(int)
Item (3) contains the users code for the constructor. At some point GCC
then gets the FUNCTION_DECL node for (3) and creates two "clones" of (3)
which are (1) and (2) I think these are referred to as in-charge and not
in-charge constructors. From what I understand these clones are just an
alias for the original function. However you are unable to get the
DECL_SAVED_TREE() from them which gives the actual code for the
constructor.
All code that uses constructors will make use of these __comp_ctor ()
and __base_ctor () like functions and NOT the user defined MyClass()
constructor, i think this is done because it is simpler than the
alternative of trying to use the MyClass::MyClass(int) function directly.
Anyhow, the simple way of finding the original function (3) from any
clone (1) and (2) is to use the macro: DECL_CLONED_FUNCTION(fndecl). For
a function that is a clone of another function, this will return the
original function that was cloned, in our case (3)
I failed to understand what it is meant when a function is a clone, and
so assumed that the "implementation" of the __comp_ctor () function
(which is a clone) would have a CALL_EXPR node in it somewhere for the
(3) FUNCTION_DECL, where from what i understand now it seems to just be
an alias for it.
Part of what I have found confusing is that there are "deleting"
destructors, which made me think that there was some extra code as part
of this __deleting_dtor () that woud free the memory or something like
that. Maybe this is the case, but I do not need to know that for my
situation.
Hope this can help someone else.
Thanks,
Brendon.
Re: Re: LOOP_HEADER tree code?
Hello, > On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote: > > > actually, that will be trivial once jump threading updates loop properly > > (I have a patch for that). > I'd like to see that. > > I recall poking at having threading update things like loop exit > points and gave up. The problem is you could thread to a loop > exit, which in turn might move the loop exit edge to a new > point in the CFG. Furthermore, all the statements dominated > by the new loop exit edge are no longer in the loop (when they > previously were part of the loop). > > It's possible these problems could be solved by querying the > dominator structures, but IIRC they aren't accurate at this > point. what my patch does is keeping the loops up-to-date. To do that, I had to disable some of the threadings (mostly those that made us create new subloops of the existing loops); on the other hand, some other threadings that are now forbidden turned out to be valid, and overall I think none of the important cases is affected. I will update and submit the patch sometime later this week. > Your updates may be simpler/easier since you're updating > something different. > > [ This was a couple years ago, so if I've got details wrong, > please forgive me. ] > > > > Which is IMHO good, as it will at least ensure that they preserve loops, > > in case it is really relevant for them -- just now, I do not see how > > code motion could affect loop structures (unless it changes CFG) -- do > > you have some concrete example of transformation that might be made > > more problematic by the existence of LOOP_HEADER node? > It wasn't a matter of changing the loop structure -- the RTL loop > optimizer had 3 or 4 notes IIRC and the location of each note > in relation to code labels and other insns was important. Code > motion would sometimes place an insn between the note and a > label. That in turn caused the loop optimizer to barf. There > were also problems with edge splitting doing similar kinds of > things. Main source of these problems with the loop notes was that their validity was never verified (only in the loop optimizer itself); so you did not know you made something wrong with them, until some problem in the loop optimizer surfaced. This should not be the case with LOOP_HEADER statements, as their validity would be verified (in verify_flow_info or verify_loop_structures). What made the problems with loop notes worse was that loop discovery itself was based on them. This meant that it was quite easy to get the loop optimizer confused if you changed the positions of the notes. Since nowadays the loop discovery is based purely on CFG, this would not be a problem. For these reasons, I do not think that making the optimizers keep LOOP_HEADER statements and loops in sync would be too difficult (at least not more difficult than making the optimizers to keep CFG and loop structures in sync). Zdenek
au sujet de gcc
Bonjour Est ce que votre organisation (gcc) utilise ou prévoit utiliser le télémarketing à court ou moyen terme ? Nous pouvons vous aider. Visiter le http://www.telemarketing.ca.cx/ Agence de télémarketing JL, est une entreprise qui se spécialise depuis plus de 20 ans dans l'exécution de mandats de télémarketing nécessitant des appels téléphoniques vers les entreprises et les consommateurs. Le professionnalisme et la qualité de nos représentants nous permettront de devenir un partenaire important dans l'augmentation de vos ventes à court terme. Nous sommes une entreprise souple, pouvant accommoder la plupart des mandats, des projets les plus modestes nécessitant que quelques heures de contacts téléphoniques aux plus importants nécessitant une campagne d'envergure. Nous agissons à titre de sous - traitant auprès de multiples entreprises, autant des entreprises nationales connues que de PME, ici au Québec. Si vous avez besoin de renseignements rapides, appelez nous sans oblogations directement au 1-866-756-6999 sur les heures d'affaires. Cordialement, Jean Lucier, Directeur, 1-866-756-6999 Visitez le http://www.telemarketing.ca.cx/ Notre entreprise assure que cette communication ponctuelle ne sont en rien du «pourriel». Tous les courriels dont nous disposons ont été recueillis au fil des dernières mois soit par contact téléphonique,la consultation de votre site, en personne ou par référence. Si vous ne désirez plus d'informations de notre part, svp écrire à [EMAIL PROTECTED] Nous respecterons votre décision.
