* Mainline space problem @ 2004-08-30 3:14 Bradley Lucier 2004-08-31 3:17 ` James E Wilson 0 siblings, 1 reply; 23+ messages in thread From: Bradley Lucier @ 2004-08-30 3:14 UTC (permalink / raw) To: gcc; +Cc: Bradley Lucier Right now, the bug in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852 is making it more difficult for me to test the correctness of the generated code. (I know the code's not correct, but I'm trying to find a suitable test case to diagnose, and that's hard when some of the modules don't even compile because cc1 requires more than 2GB of RAM.) It would be nice if someone could try to fix the problem here. I don't know why it's still marked as UNCONFIRMED when Andrew has noted the precise allocation that fails. Brad ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-30 3:14 Mainline space problem Bradley Lucier @ 2004-08-31 3:17 ` James E Wilson 2004-08-31 3:56 ` Daniel Berlin ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: James E Wilson @ 2004-08-31 3:17 UTC (permalink / raw) To: Bradley Lucier; +Cc: gcc Bradley Lucier wrote: > It would be nice if someone could try to fix the problem here. I don't > know why it's still marked as UNCONFIRMED when Andrew has noted the > precise allocation that fails. The problem Andrew pointed out isn't something that can be fixed. global builds a conflict matrix that is quadratic in number of pseudos. So if you have 100K+ pseudos, then you need 2GB+ of memory. This can't be fixed, at least not in global. The only way to solve this is to try to reduce the number of pseudos created. As this testcase has a very large function that uses a lot of &&label extensions, coding this differently would help, though I realize this may not be feasible. Since we already have 100K+ pseudos in the .rtl dump, and they all appear to be used, there is probably nothing we can do in the RTL optimizer. So the only option would be to look for a way to throttle the tree/gimple optimizer to avoid over optimizing very large functions to the point where gcc will run out of memory. This isn't a very interesting task for a volunteer. Since you care more about this problem than anyone else at the moment, you might try tracking down the problem a bit more. If the testcase really did work two months ago, then you might be able to find a patch that broke it. If you can do that, then you are more likely to find someone to look at the problem. Otherwise, it isn't clear that anything broke. This may just be a side-effect of the new tree/gimple optimizers. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 3:17 ` James E Wilson @ 2004-08-31 3:56 ` Daniel Berlin 2004-08-31 15:54 ` Jeffrey A Law 2004-08-31 18:33 ` James E Wilson 2004-09-01 2:14 ` Bradley Lucier 2004-09-01 4:16 ` Bradley Lucier 2 siblings, 2 replies; 23+ messages in thread From: Daniel Berlin @ 2004-08-31 3:56 UTC (permalink / raw) To: James E Wilson; +Cc: Bradley Lucier, gcc On Mon, 30 Aug 2004, James E Wilson wrote: > Bradley Lucier wrote: >> It would be nice if someone could try to fix the problem here. I don't >> know why it's still marked as UNCONFIRMED when Andrew has noted the >> precise allocation that fails. > > The problem Andrew pointed out isn't something that can be fixed. global > builds a conflict matrix that is quadratic in number of pseudos. So if you > have 100K+ pseudos, then you need 2GB+ of memory. This can't be fixed, at > least not in global. Only if the conflict matrix is 1. Dense. 2. Bidirectional. Otherwise, you could use sparse bitmaps (in case of 1 not being gtrue) , and/or a lower-triangular bitmatrix (in case of 2 not being true). Unless global is doing something completely weird (it may be, i haven't looked at since i worked on new-ra), the conflict matrix is unidirectional (IE if x conflicts with y, then y must conflict with x). Thus you can use a lower-triangular bitmatrix, and save half the memory. . This is a standard technique for interference graphs in graph coloring register allocators. See http://citeseer.ist.psu.edu/cooper88how.html (It's a little out of date these days, but still goes over this stuff). --Dan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 3:56 ` Daniel Berlin @ 2004-08-31 15:54 ` Jeffrey A Law 2004-08-31 18:33 ` James E Wilson 1 sibling, 0 replies; 23+ messages in thread From: Jeffrey A Law @ 2004-08-31 15:54 UTC (permalink / raw) To: Daniel Berlin; +Cc: James E Wilson, Bradley Lucier, gcc On Mon, 2004-08-30 at 21:31, Daniel Berlin wrote: > On Mon, 30 Aug 2004, James E Wilson wrote: > > > Bradley Lucier wrote: > >> It would be nice if someone could try to fix the problem here. I don't > >> know why it's still marked as UNCONFIRMED when Andrew has noted the > >> precise allocation that fails. > > > > The problem Andrew pointed out isn't something that can be fixed. global > > builds a conflict matrix that is quadratic in number of pseudos. So if you > > have 100K+ pseudos, then you need 2GB+ of memory. This can't be fixed, at > > least not in global. > > Only if the conflict matrix is > 1. Dense. > 2. Bidirectional. > > Otherwise, you could use sparse bitmaps (in case of 1 not being gtrue) , > and/or a lower-triangular bitmatrix (in case of 2 not being true). I don't think we're using a lower triangular bitmap at this point; see "mirror_conflicts" in global.c jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 3:56 ` Daniel Berlin 2004-08-31 15:54 ` Jeffrey A Law @ 2004-08-31 18:33 ` James E Wilson 2004-08-31 18:39 ` Joern Rennecke 2004-08-31 18:40 ` Daniel Berlin 1 sibling, 2 replies; 23+ messages in thread From: James E Wilson @ 2004-08-31 18:33 UTC (permalink / raw) To: Daniel Berlin; +Cc: Bradley Lucier, gcc Daniel Berlin wrote: > Unless global is doing something completely weird (it may be, i haven't > looked at since i worked on new-ra), the conflict matrix is > unidirectional (IE if x conflicts with y, then y must conflict with x). > Thus you can use a lower-triangular bitmatrix, and save half the memory. If we save half the memory, then we still need over a gigabyte, and we still run out of memory. Constant factors don't help much with quadratic problems. They are still quadratic. If we try using a sparse bitmaps, then we are adding unnecessary overhead for the most common case which will make the compiler run even slower than it already does. If we try to use simple arrays for the common case, and sparse bitmaps for the big function case, then we are adding complexity, which will make maintenance harder. I did of course consider the possibility of using some kind of sparse matrix representation here, but I didn't think it was worth mentioning. I think we should instead be looking at reducing the number of pseudo regs generated for this testcase. By the way, I did try -fnew-ra. It used over 980MB and then died with a segfault. I didn't bother looking at why, but I figured if -fnew-ra couldn't handle it, then fixing global to handle it was probably not feasible. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 18:33 ` James E Wilson @ 2004-08-31 18:39 ` Joern Rennecke 2004-08-31 18:40 ` Daniel Berlin 1 sibling, 0 replies; 23+ messages in thread From: Joern Rennecke @ 2004-08-31 18:39 UTC (permalink / raw) To: James E Wilson; +Cc: Daniel Berlin, Bradley Lucier, gcc > If we try using a sparse bitmaps, then we are adding unnecessary > overhead for the most common case which will make the compiler run even > slower than it already does. I'm not so sure about that. Even for moderately sized problems, the matrix tends to be sparse, and walking over all the pseudos that conflict with one particular pseudo is an operation that takes a appreciable part of the time accessing the data. If that were not the case, mirroring the conflict matrix and using word operations wouln't have yielded such a large improvement. Thus, if we use a sparse matrix representation that has decent single-bit access times and good row-walking performance, we might even speed up the compiler for the common case. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 18:33 ` James E Wilson 2004-08-31 18:39 ` Joern Rennecke @ 2004-08-31 18:40 ` Daniel Berlin 2004-08-31 20:11 ` James E Wilson 1 sibling, 1 reply; 23+ messages in thread From: Daniel Berlin @ 2004-08-31 18:40 UTC (permalink / raw) To: James E Wilson; +Cc: Bradley Lucier, gcc On Aug 31, 2004, at 2:19 PM, James E Wilson wrote: > Daniel Berlin wrote: >> Unless global is doing something completely weird (it may be, i >> haven't looked at since i worked on new-ra), the conflict matrix is >> unidirectional (IE if x conflicts with y, then y must conflict with >> x). >> Thus you can use a lower-triangular bitmatrix, and save half the >> memory. > > If we save half the memory, then we still need over a gigabyte, and we > still run out of memory. Constant factors don't help much with > quadratic problems. They are still quadratic. You honestly believe it is not much better to use half as much memory? That 2 gigabytes and 1 gigabyte aren't that different? > > If we try using a sparse bitmaps, then we are adding unnecessary > overhead for the most common case which will make the compiler run > even slower than it already does. What makes you think that the common case is the dense case? It's much more likely to be sparse, otherwise 16 registers wouldn't be enough on most platforms when there are more than 16 pseudos in a function (and there are often hundreds). > If we try to use simple arrays for the common case, and sparse > bitmaps for the big function case, then we are adding complexity, > which will make maintenance harder. But it is very useful in other situations as well to use a hybrid list/bitmap structure. > > I did of course consider the possibility of using some kind of sparse > matrix representation here, but I didn't think it was worth > mentioning. I think we should instead be looking at reducing the > number of pseudo regs generated for this testcase. Sure, but that doesn't mean you should avoid improving global simply because it might not be enough. That would tell me you should improve global, *and* do something else. Then you save even more memory and time. > By the way, I did try -fnew-ra. It used over 980MB and then died with > a segfault. I didn't bother looking at why, but I figured if -fnew-ra > couldn't handle it, then fixing global to handle it was probably not > feasible. > > Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 18:40 ` Daniel Berlin @ 2004-08-31 20:11 ` James E Wilson 2004-08-31 20:32 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: James E Wilson @ 2004-08-31 20:11 UTC (permalink / raw) To: Daniel Berlin; +Cc: Bradley Lucier, gcc On Tue, 2004-08-31 at 11:36, Daniel Berlin wrote: > You honestly believe it is not much better to use half as much memory? > That 2 gigabytes and 1 gigabyte aren't that different? This is an oversimplification, and an insult. Yes, of course, using half the memory is better. But it doesn't fix the underlying bug, as we still need more memory than what is available for this testcase, and mainline still uses far more memory than gcc-3.4. Also, we need to keep in mind that any change to data structures may add overhead that may make the compiler slower. The speed of the compiler is a common complaint. We should be keeping this in mind. The underlying problem here, as I have said twice already, is that we have too many pseudo regs. Gcc-3.4 needs only about 9K pseudos. Mainline needs about 129K pseudos. That leads to about a 200 times increase in the memory usage needed, because of the quadratic factor. We can reduce that to 100 times by using a lower-triangular bitmatrix as you mention, but I think this is the wrong approach, as it doesn't fix the underlying problem, which is too many pseudos. I believe we should instead be looking at why we have so many pseudos for this testcase. We can reduce the memory usage even farther by using sparse matrices, but that will add even more overhead. If we replace array references with function calls, then I think it is likely for the common case that there will be a performance hit. This would eliminate the quadratic factor which would let us compile large function though. So there is a trade off here, we can make the compiler slower in the common case in order to increase the size of functions that we can compile. It is far from obvious that this is a good tradeoff. > What makes you think that the common case is the dense case? This is a false assumption, and an insult. I never said the common case was dense. What I said, in both previous messages, is that we have too many pseudo regs. The common case is a small enough number of pseudos such that the quadratic memory allocation here isn't a problem. Obviously the matrix is sparse, particularly in this case. Apparently you think I'm stupid. I'm not. I don't understand why you feel the need to insult me so. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 20:11 ` James E Wilson @ 2004-08-31 20:32 ` Robert Dewar 2004-08-31 20:34 ` Daniel Berlin 2004-09-01 19:36 ` Geert Bosch 2 siblings, 0 replies; 23+ messages in thread From: Robert Dewar @ 2004-08-31 20:32 UTC (permalink / raw) To: James E Wilson; +Cc: Daniel Berlin, Bradley Lucier, gcc James E Wilson wrote: > What I said, in both previous messages, is that we have too > many pseudo regs. The common case is a small enough number of pseudos > such that the quadratic memory allocation here isn't a problem. I absolutely agree that the problem is too many pseudo-registers. There is no justification for the large number we see here. When you have performance of N**2/K increasing K by a small factor is likely to be much less significant than reducing N or the 2. Now it is true that using a sparse matrix representation would indeed reduce the 2, but I agree with JW that this would likely introduce unacceptable overhead. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 20:11 ` James E Wilson 2004-08-31 20:32 ` Robert Dewar @ 2004-08-31 20:34 ` Daniel Berlin 2004-09-01 19:36 ` Geert Bosch 2 siblings, 0 replies; 23+ messages in thread From: Daniel Berlin @ 2004-08-31 20:34 UTC (permalink / raw) To: James E Wilson; +Cc: Bradley Lucier, gcc On Aug 31, 2004, at 3:55 PM, James E Wilson wrote: > On Tue, 2004-08-31 at 11:36, Daniel Berlin wrote: >> You honestly believe it is not much better to use half as much memory? >> That 2 gigabytes and 1 gigabyte aren't that different? > > This is an oversimplification, and an insult. I didn't mean for it to come across as an insult. > > Apparently you think I'm stupid. I'm not. I don't understand why you > feel the need to insult me so. > Jim, I certainly didn't mean to insult you, and I certainly don't believe you are stupid. > -- > Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 20:11 ` James E Wilson 2004-08-31 20:32 ` Robert Dewar 2004-08-31 20:34 ` Daniel Berlin @ 2004-09-01 19:36 ` Geert Bosch 2 siblings, 0 replies; 23+ messages in thread From: Geert Bosch @ 2004-09-01 19:36 UTC (permalink / raw) To: James E Wilson; +Cc: Daniel Berlin, Bradley Lucier, gcc On Aug 31, 2004, at 15:55, James E Wilson wrote: > The underlying problem here, as I have said twice already, is that we > have too many pseudo regs. Gcc-3.4 needs only about 9K pseudos. > Mainline needs about 129K pseudos. That leads to about a 200 times > increase in the memory usage needed, because of the quadratic factor. A good way of preventing such quadratic behavior, is to divide the problem into smaller parts and handle them separately. For example, split a very large function into parts that are processed individually and insert the necessary code to connect the parts together. If the problem is very large, chances are the overhead introduced by the split is small in comparison to the total cost of the function. Also, forcing such a split shortens live ranges and potentially allows for more space reuse, further reducing the overhead of the split. Currently, the optimizers try to smash an entire function, including all code that may have been inlined, into a flat piece of code without scopes. Combined with SSA and tree-level optimizations that work on entire functions and generally may extend live ranges of variables, this may explain why we need so many pseudos in the first place. -Geert ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 3:17 ` James E Wilson 2004-08-31 3:56 ` Daniel Berlin @ 2004-09-01 2:14 ` Bradley Lucier 2004-09-01 4:16 ` Bradley Lucier 2 siblings, 0 replies; 23+ messages in thread From: Bradley Lucier @ 2004-09-01 2:14 UTC (permalink / raw) To: James E Wilson; +Cc: Bradley Lucier, gcc Thank you for your response. I'm not a great user of shell scripts, so I haven't yet figured out how to use reg_search, but I did cvs_update my source tree to June 14 and got the following result: [descartes:~/programs/gcc/mainline] lucier% objdir/gcc/cc1 -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -g -DHAVE_CONFIG_H _t-c-1.i ___H__20___t_2d_c_2d_1 {GC 18028k -> 8652k} {GC 11710k -> 9765k} {GC 15697k -> 11530k} {GC 15292k -> 10729k} {GC 15063k -> 10842k} {GC 14845k -> 12163k} {GC 15911k -> 13031k} ___init_proc {GC 17168k -> 8421k} ____20___t_2d_c_2d_1 Execution times (seconds) garbage collection : 0.61 ( 5%) usr 0.02 ( 0%) sys 1.08 ( 4%) wall cfg construction : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall cfg cleanup : 0.13 ( 1%) usr 0.00 ( 0%) sys 0.21 ( 1%) wall CFG verifier : 0.62 ( 5%) usr 0.01 ( 0%) sys 0.86 ( 3%) wall trivially dead code : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall life analysis : 0.37 ( 3%) usr 0.13 ( 2%) sys 0.65 ( 3%) wall life info update : 0.10 ( 1%) usr 0.00 ( 0%) sys 0.16 ( 1%) wall alias analysis : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall register scan : 0.07 ( 1%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall rebuild jump labels : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall preprocessing : 0.63 ( 5%) usr 1.20 (21%) sys 2.38 (10%) wall lexical analysis : 1.15 ( 9%) usr 2.00 (36%) sys 4.56 (18%) wall parser : 0.97 ( 8%) usr 1.26 (23%) sys 3.11 (12%) wall tree gimplify : 0.27 ( 2%) usr 0.00 ( 0%) sys 0.38 ( 2%) wall tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall tree CFG construction : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall tree CFG cleanup : 0.25 ( 2%) usr 0.00 ( 0%) sys 0.31 ( 1%) wall tree PTA : 0.19 ( 2%) usr 0.00 ( 0%) sys 0.21 ( 1%) wall tree alias analysis : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall tree PHI insertion : 0.17 ( 1%) usr 0.00 ( 0%) sys 0.27 ( 1%) wall tree SSA rewrite : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall tree SSA other : 0.18 ( 1%) usr 0.19 ( 3%) sys 0.52 ( 2%) wall tree operand scan : 0.12 ( 1%) usr 0.22 ( 4%) sys 0.69 ( 3%) wall dominator optimization: 1.02 ( 8%) usr 0.07 ( 1%) sys 1.37 ( 5%) wall tree CCP : 0.06 ( 0%) usr 0.01 ( 0%) sys 0.11 ( 0%) wall tree split crit edges : 0.08 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall tree PRE : 0.14 ( 1%) usr 0.10 ( 2%) sys 0.32 ( 1%) wall tree forward propagate: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall tree conservative DCE : 0.07 ( 1%) usr 0.00 ( 0%) sys 0.13 ( 1%) wall tree aggressive DCE : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall tree DSE : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall tree copy headers : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall tree SSA to normal : 0.34 ( 3%) usr 0.00 ( 0%) sys 0.50 ( 2%) wall tree rename SSA copies: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall tree SSA verifier : 0.86 ( 7%) usr 0.02 ( 0%) sys 1.37 ( 5%) wall tree STMT verifier : 0.17 ( 1%) usr 0.02 ( 0%) sys 0.18 ( 1%) wall dominance frontiers : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall expand : 0.49 ( 4%) usr 0.05 ( 1%) sys 0.72 ( 3%) wall varconst : 0.02 ( 0%) usr 0.01 ( 0%) sys 0.08 ( 0%) wall jump : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall CSE : 0.13 ( 1%) usr 0.03 ( 1%) sys 0.25 ( 1%) wall loop analysis : 0.15 ( 1%) usr 0.02 ( 0%) sys 0.20 ( 1%) wall branch prediction : 0.15 ( 1%) usr 0.01 ( 0%) sys 0.19 ( 1%) wall flow analysis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall combiner : 0.19 ( 2%) usr 0.03 ( 1%) sys 0.30 ( 1%) wall if-conversion : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall local alloc : 0.16 ( 1%) usr 0.02 ( 0%) sys 0.24 ( 1%) wall global alloc : 0.79 ( 6%) usr 0.09 ( 2%) sys 1.27 ( 5%) wall reload CSE regs : 0.15 ( 1%) usr 0.01 ( 0%) sys 0.21 ( 1%) wall flow 2 : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall if-conversion 2 : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall rename registers : 0.18 ( 1%) usr 0.00 ( 0%) sys 0.25 ( 1%) wall scheduling 2 : 0.25 ( 2%) usr 0.01 ( 0%) sys 0.34 ( 1%) wall shorten branches : 0.04 ( 0%) usr 0.01 ( 0%) sys 0.05 ( 0%) wall final : 0.15 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall symout : 0.00 ( 0%) usr 0.03 ( 1%) sys 0.02 ( 0%) wall rest of compilation : 0.10 ( 1%) usr 0.02 ( 0%) sys 0.15 ( 1%) wall TOTAL : 12.22 5.60 25.01 Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks. [descartes:~/programs/gcc/mainline] lucier% objdir/gcc/xgcc -v Reading specs from /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin7.5.0/3.5.0/specs Configured with: ../configure --prefix=/pkgs/gcc-mainline --enable-languages=c Thread model: posix gcc version 3.5.0 20040614 (experimental) So it worked then, and doesn't work now. Perhaps someone could help me out with how to use reg_search to find out where things changed. (Unfortunately, there were many times in the last 2 1/2 months when the mainline didn't bootstrap.) Brad ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-08-31 3:17 ` James E Wilson 2004-08-31 3:56 ` Daniel Berlin 2004-09-01 2:14 ` Bradley Lucier @ 2004-09-01 4:16 ` Bradley Lucier 2004-09-01 18:22 ` Bradley Lucier 2004-09-03 5:12 ` James E Wilson 2 siblings, 2 replies; 23+ messages in thread From: Bradley Lucier @ 2004-09-01 4:16 UTC (permalink / raw) To: James E Wilson; +Cc: Bradley Lucier, gcc By updating my mainline tree with commands like this: cvs update -D "July 22, 2004" I found that the example program compiled on July 20 and didn't on July 24. Bootstrap failed on July 22. I'll work more on this later. Brad ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-01 4:16 ` Bradley Lucier @ 2004-09-01 18:22 ` Bradley Lucier 2004-09-01 18:26 ` Dave Korn 2004-09-01 18:43 ` Mike Stump 2004-09-03 5:12 ` James E Wilson 1 sibling, 2 replies; 23+ messages in thread From: Bradley Lucier @ 2004-09-01 18:22 UTC (permalink / raw) To: gcc; +Cc: Bradley Lucier The test file compiled on July 23 and didn't on July 24. When I say cvs update -D "July 23, 2004" I don't know at what precise time the tree is backed up to. But after that command it worked and after cvs update -D "July 24, 2004" it didn't. Brad ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Mainline space problem 2004-09-01 18:22 ` Bradley Lucier @ 2004-09-01 18:26 ` Dave Korn 2004-09-01 18:43 ` Mike Stump 1 sibling, 0 replies; 23+ messages in thread From: Dave Korn @ 2004-09-01 18:26 UTC (permalink / raw) To: 'Bradley Lucier', gcc > -----Original Message----- > From: gcc-owner On Behalf Of Bradley Lucier > Sent: 01 September 2004 19:22 > The test file compiled on July 23 and didn't on July 24. > > When I say > > cvs update -D "July 23, 2004" > > I don't know at what precise time the tree is backed up to. > But after that command it worked and after > > cvs update -D "July 24, 2004" > > it didn't. > > Brad Check the man/info page for cvs. You can specify a precise time along with the date, so you can subdivide that 24-hour period if you want to. cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-01 18:22 ` Bradley Lucier 2004-09-01 18:26 ` Dave Korn @ 2004-09-01 18:43 ` Mike Stump 2004-09-01 23:02 ` Janis Johnson 1 sibling, 1 reply; 23+ messages in thread From: Mike Stump @ 2004-09-01 18:43 UTC (permalink / raw) To: Bradley Lucier; +Cc: gcc On Wednesday, September 1, 2004, at 11:22 AM, Bradley Lucier wrote: > The test file compiled on July 23 and didn't on July 24. > > When I say > > cvs update -D "July 23, 2004" > > I don't know at what precise time the tree is backed up to. I always use things like -D "July 23, 2004 1:00", then, I + or - 12, then 6, then 3.... coupled with a diff on ChangeLog one can direct the search more intelligently based upon the changes there... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-01 18:43 ` Mike Stump @ 2004-09-01 23:02 ` Janis Johnson 2004-09-01 23:18 ` Mike Stump 0 siblings, 1 reply; 23+ messages in thread From: Janis Johnson @ 2004-09-01 23:02 UTC (permalink / raw) To: Mike Stump; +Cc: Bradley Lucier, gcc On Wed, Sep 01, 2004 at 11:43:28AM -0700, Mike Stump wrote: > On Wednesday, September 1, 2004, at 11:22 AM, Bradley Lucier wrote: > > >The test file compiled on July 23 and didn't on July 24. > > > >When I say > > > > cvs update -D "July 23, 2004" > > > >I don't know at what precise time the tree is backed up to. > > I always use things like -D "July 23, 2004 1:00", then, I + or - 12, > then 6, then 3.... coupled with a diff on ChangeLog one can direct the > search more intelligently based upon the changes there... I always use UTC to avoid confusion about which time zone is being used where. The times in 'cvs log' output are UTC. Janis ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-01 23:02 ` Janis Johnson @ 2004-09-01 23:18 ` Mike Stump 0 siblings, 0 replies; 23+ messages in thread From: Mike Stump @ 2004-09-01 23:18 UTC (permalink / raw) To: Janis Johnson; +Cc: Bradley Lucier, gcc On Sep 1, 2004, at 4:02 PM, Janis Johnson wrote: > I always use UTC to avoid confusion about which time zone is being used > where. The times in 'cvs log' output are UTC. Unless you use a new cvs which does it in local time. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-01 4:16 ` Bradley Lucier 2004-09-01 18:22 ` Bradley Lucier @ 2004-09-03 5:12 ` James E Wilson 2004-09-03 17:40 ` Bradley Lucier 1 sibling, 1 reply; 23+ messages in thread From: James E Wilson @ 2004-09-03 5:12 UTC (permalink / raw) To: Bradley Lucier; +Cc: gcc, gcc-patches [-- Attachment #1: Type: text/plain, Size: 921 bytes --] On Tue, 2004-08-31 at 21:17, Bradley Lucier wrote: > I found that the example program compiled on July 20 and didn't on July > 24. The change that broke it is a cleanup patch from Richard Henderson. http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02228.html The part that specifically caused the problem is the may_be_aliased change. Instrumenting this, I see that the old one returns true for extern variables, but the new one returns false for them. This is because there is a !TREE_STATIC check for automatic variables, but externs also are !TREE_STATIC. This seems to be a legitimate bug. With the attached patch, the may_be_aliased function gives the same result as before for all variables for this testcase. The testcase can be compiled again, using about 10K pseudos instead of about 130K pseudos. I started a ppc-darwin build to test this. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com [-- Attachment #2: patch.alias.extern --] [-- Type: text/plain, Size: 1836 bytes --] 2004-09-02 James E Wilson <wilson@specifixinc.com> * tree-ssa-alias.c (may_be_aliased): Move TREE_STATIC check after DECL_EXTERNAL check. Index: tree-ssa-alias.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v retrieving revision 2.25 diff -p -r2.25 tree-ssa-alias.c *** tree-ssa-alias.c 25 Aug 2004 21:21:16 -0000 2.25 --- tree-ssa-alias.c 3 Sep 2004 04:44:03 -0000 *************** may_be_aliased (tree var) *** 2467,2481 **** if (TREE_ADDRESSABLE (var)) return true; - /* Automatic variables can't have their addresses escape any other way. */ - if (!TREE_STATIC (var)) - return false; - /* Globally visible variables can have their addresses taken by other translation units. */ if (DECL_EXTERNAL (var) || TREE_PUBLIC (var)) return true; /* If we're in unit-at-a-time mode, then we must have seen all occurrences of address-of operators, and so we can trust TREE_ADDRESSABLE. Otherwise we can only be sure the variable isn't addressable if it's local to the --- 2467,2483 ---- if (TREE_ADDRESSABLE (var)) return true; /* Globally visible variables can have their addresses taken by other translation units. */ if (DECL_EXTERNAL (var) || TREE_PUBLIC (var)) return true; + /* Automatic variables can't have their addresses escape any other way. + This must be after the check for global variables, as extern declarations + do not have TREE_STATIC set. */ + if (!TREE_STATIC (var)) + return false; + /* If we're in unit-at-a-time mode, then we must have seen all occurrences of address-of operators, and so we can trust TREE_ADDRESSABLE. Otherwise we can only be sure the variable isn't addressable if it's local to the ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-03 5:12 ` James E Wilson @ 2004-09-03 17:40 ` Bradley Lucier 2004-09-03 17:48 ` Diego Novillo 0 siblings, 1 reply; 23+ messages in thread From: Bradley Lucier @ 2004-09-03 17:40 UTC (permalink / raw) To: James E Wilson; +Cc: Bradley Lucier, gcc, gcc-patches On Sep 3, 2004, at 12:12 AM, James E Wilson wrote: > With the attached patch, the may_be_aliased function gives the same > result as before for all variables for this testcase. The testcase can > be compiled again, using about 10K pseudos instead of about 130K > pseudos. Thank you for the patch. Unfortunately, mainline doesn't bootstrap with or without the patch, with a message of: /Users/lucier/programs/gcc/mainline/objdir/gcc/xgcc -shared-libgcc -B/Users/lucier/programs/gcc/mainline/objdir/gcc/ -nostdinc++ -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ libstdc++-v3/src -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ libstdc++-v3/src/.libs -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/bin/ -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/lib/ -isystem /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/include -isystem /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/sys-include -DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj -I../../../libjava -Iinclude -I../../../libjava/include -I../../../libjava/../boehm-gc/include -I../boehm-gc/include -I../../../libjava/libltdl -I../../../libjava/libltdl -I../../../libjava/.././libjava/../gcc -I../../../libjava/../zlib -I../../../libjava/../libffi/include -I../libffi/include -O2 -g -O2 -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/pkgs/gcc-mainline\" -DLIBDIR=\"/pkgs/gcc-mainline/lib\" -DBOOT_CLASS_PATH=\"/pkgs/gcc-mainline/share/java/libgcj-3.5.0.jar\" -DJAVA_EXT_DIRS=\"/pkgs/gcc-mainline/share/java/ext\" -g -O2 -MT interpret.lo -MD -MP -MF .deps/interpret.Tpo -c ../../../libjava/interpret.cc -fno-common -DPIC -o .libs/interpret.o [address=ffffff9d pc=003dd7e8] ../../../libjava/interpret.cc: In member function `void _Jv_InterpMethod::run(void*, ffi_raw*)': ../../../libjava/interpret.cc:3220: internal compiler error: Segmentation Fault ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-03 17:40 ` Bradley Lucier @ 2004-09-03 17:48 ` Diego Novillo 2004-09-03 18:05 ` Andrew Pinski 0 siblings, 1 reply; 23+ messages in thread From: Diego Novillo @ 2004-09-03 17:48 UTC (permalink / raw) To: Bradley Lucier; +Cc: James E Wilson, gcc, gcc-patches On Fri, 2004-09-03 at 13:40, Bradley Lucier wrote: > On Sep 3, 2004, at 12:12 AM, James E Wilson wrote: > > > With the attached patch, the may_be_aliased function gives the same > > result as before for all variables for this testcase. The testcase can > > be compiled again, using about 10K pseudos instead of about 130K > > pseudos. > > Thank you for the patch. Unfortunately, mainline doesn't bootstrap > with or without the patch, with a message of: > > /Users/lucier/programs/gcc/mainline/objdir/gcc/xgcc -shared-libgcc > -B/Users/lucier/programs/gcc/mainline/objdir/gcc/ -nostdinc++ > -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ > libstdc++-v3/src > -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ > libstdc++-v3/src/.libs > -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/bin/ > -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/lib/ -isystem > /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/include -isystem > /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/sys-include > -DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj > -I../../../libjava -Iinclude -I../../../libjava/include > -I../../../libjava/../boehm-gc/include -I../boehm-gc/include > -I../../../libjava/libltdl -I../../../libjava/libltdl > -I../../../libjava/.././libjava/../gcc -I../../../libjava/../zlib > -I../../../libjava/../libffi/include -I../libffi/include -O2 -g -O2 > -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum > -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -Wextra -Wall -D_GNU_SOURCE > -DPREFIX=\"/pkgs/gcc-mainline\" -DLIBDIR=\"/pkgs/gcc-mainline/lib\" > -DBOOT_CLASS_PATH=\"/pkgs/gcc-mainline/share/java/libgcj-3.5.0.jar\" > -DJAVA_EXT_DIRS=\"/pkgs/gcc-mainline/share/java/ext\" -g -O2 -MT > interpret.lo -MD -MP -MF .deps/interpret.Tpo -c > ../../../libjava/interpret.cc -fno-common -DPIC -o .libs/interpret.o > [address=ffffff9d pc=003dd7e8] > ../../../libjava/interpret.cc: In member function `void > _Jv_InterpMethod::run(void*, ffi_raw*)': > ../../../libjava/interpret.cc:3220: internal compiler error: > Segmentation Fault > Yes. I ran into this one this morning. What I observed was that: (gdb) bt #0 may_trap_p (x=0xffffff9d) at gcc/rtlanal.c:2311 #1 0x102605a4 in try_split (pat=Variable "pat" is not available.) at gcc/emit-rtl.c:3329 #2 0x103a93d4 in split_insn (insn=0x4114f3c0) at gcc/recog.c:2645 #3 0x103a957c in split_all_insns (upd_life=0) at gcc/recog.c:2723 #4 0x10428098 in rest_of_handle_flow2 () (gdb) l 3329 if (CALL_P (insn) 3330 || (flag_non_call_exceptions 3331 && may_trap_p (PATTERN (insn)))) (gdb) pr insn (note 9158 0 0 NOTE_INSN_DELETED) I'm not quite sure when this was introduced as my ppc box had been off for a couple of days. Diego. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-03 17:48 ` Diego Novillo @ 2004-09-03 18:05 ` Andrew Pinski 2004-09-06 21:18 ` James E Wilson 0 siblings, 1 reply; 23+ messages in thread From: Andrew Pinski @ 2004-09-03 18:05 UTC (permalink / raw) To: Diego Novillo; +Cc: Bradley Lucier, James E Wilson, gcc, gcc-patches On Sep 3, 2004, at 10:48 AM, Diego Novillo wrote: > On Fri, 2004-09-03 at 13:40, Bradley Lucier wrote: >> On Sep 3, 2004, at 12:12 AM, James E Wilson wrote: >> >>> With the attached patch, the may_be_aliased function gives the same >>> result as before for all variables for this testcase. The testcase >>> can >>> be compiled again, using about 10K pseudos instead of about 130K >>> pseudos. >> >> Thank you for the patch. Unfortunately, mainline doesn't bootstrap >> with or without the patch, with a message of: >> > Yes. I ran into this one this morning. What I observed was that: > > (gdb) bt > #0 may_trap_p (x=0xffffff9d) > at gcc/rtlanal.c:2311 > #1 0x102605a4 in try_split (pat=Variable "pat" is not available.) > at gcc/emit-rtl.c:3329 > #2 0x103a93d4 in split_insn (insn=0x4114f3c0) > at gcc/recog.c:2645 > #3 0x103a957c in split_all_insns (upd_life=0) > at gcc/recog.c:2723 > #4 0x10428098 in rest_of_handle_flow2 () > > (gdb) l > 3329 if (CALL_P (insn) > 3330 || (flag_non_call_exceptions > 3331 && may_trap_p (PATTERN (insn)))) > > (gdb) pr insn > (note 9158 0 0 NOTE_INSN_DELETED) > > I'm not quite sure when this was introduced as my ppc box had been off > for a couple of days. I found out that the patch which introduced this failure was (which means it was latent bug): +2004-09-02 James E Wilson <wilson@specifixinc.com> + + * common.opt (ftrapping-math): Default to on. + See <http://gcc.gnu.org/ml/gcc-regression/2004-09/msg00006.html> for the preprocessed source and instructions on how to reproduce it. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Mainline space problem 2004-09-03 18:05 ` Andrew Pinski @ 2004-09-06 21:18 ` James E Wilson 0 siblings, 0 replies; 23+ messages in thread From: James E Wilson @ 2004-09-06 21:18 UTC (permalink / raw) To: Andrew Pinski; +Cc: Bradley Lucier, gcc, gcc-patches [-- Attachment #1: Type: text/plain, Size: 681 bytes --] Andrew Pinski wrote: > I found out that the patch which introduced this failure was (which > means it was latent bug): > +2004-09-02 James E Wilson <wilson@specifixinc.com> > + * common.opt (ftrapping-math): Default to on. I checked in the attached patch to fix this. Mainline bootstraps with the patch, but does not bootstrap without it. I have also started a make check, and things look fine so far. I think the patch that broke it was http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01881.html but the problem went unnoticed until now because flag_trapping_math was accidentally turned off earlier. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com [-- Attachment #2: patch.ppc.boot --] [-- Type: text/plain, Size: 913 bytes --] 2004-09-06 James E Wilson <wilson@specifixinc.com> * emit-rtl.c (try_split): Check INSN_P before may_trap_p call. Index: emit-rtl.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/emit-rtl.c,v retrieving revision 1.410 diff -p -r1.410 emit-rtl.c *** emit-rtl.c 18 Aug 2004 21:08:20 -0000 1.410 --- emit-rtl.c 6 Sep 2004 20:12:42 -0000 *************** try_split (rtx pat, rtx trial, int last) *** 3327,3333 **** while (insn != NULL_RTX) { if (CALL_P (insn) ! || (flag_non_call_exceptions && may_trap_p (PATTERN (insn)))) REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_EH_REGION, --- 3327,3333 ---- while (insn != NULL_RTX) { if (CALL_P (insn) ! || (flag_non_call_exceptions && INSN_P (insn) && may_trap_p (PATTERN (insn)))) REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_EH_REGION, ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2004-09-06 21:18 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-30 3:14 Mainline space problem Bradley Lucier 2004-08-31 3:17 ` James E Wilson 2004-08-31 3:56 ` Daniel Berlin 2004-08-31 15:54 ` Jeffrey A Law 2004-08-31 18:33 ` James E Wilson 2004-08-31 18:39 ` Joern Rennecke 2004-08-31 18:40 ` Daniel Berlin 2004-08-31 20:11 ` James E Wilson 2004-08-31 20:32 ` Robert Dewar 2004-08-31 20:34 ` Daniel Berlin 2004-09-01 19:36 ` Geert Bosch 2004-09-01 2:14 ` Bradley Lucier 2004-09-01 4:16 ` Bradley Lucier 2004-09-01 18:22 ` Bradley Lucier 2004-09-01 18:26 ` Dave Korn 2004-09-01 18:43 ` Mike Stump 2004-09-01 23:02 ` Janis Johnson 2004-09-01 23:18 ` Mike Stump 2004-09-03 5:12 ` James E Wilson 2004-09-03 17:40 ` Bradley Lucier 2004-09-03 17:48 ` Diego Novillo 2004-09-03 18:05 ` Andrew Pinski 2004-09-06 21:18 ` James E Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).