[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-01-02 12:37 --- Subject: Bug 31976 Author: rguenth Date: Wed Jan 2 12:35:38 2008 New Revision: 131257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131257 Log: 2008-01-02 Richard Guenther [EMAIL PROTECTED] PR middle-end/34093 PR middle-end/31976 * tree-ssa-operands.c (ssa_operand_alloc): Also allocate a buffer for very large number of operands instead of ICEing. * gcc.c-torture/compile/pr34093.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr34093.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-operands.c --- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-02 12:38 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Bug 31976 depends on bug 34093, which changed state. Bug 34093 Summary: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:484 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34093 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #13 from dnovillo at google dot com 2007-11-07 13:57 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On 7 Nov 2007 13:52:29 -, amacleod at redhat dot com [EMAIL PROTECTED] wrote: There is also an issue with partitioning, but it would then hide what I think is an important issue. Partitioning's problem is that it counts the number of items in the alias set and just uses that. There is only one entry for an entire SFT list, so it misses the other 819 in this particular list. The difficulty is determining how many of those SFTs are actually going to be relevant. Ideally, partitioning would share code with VOP processing so it can see exactly how many VOPs would be generated by each MEM. Agreed. The partitioner heuristics got severely skewed when we switched alias sets to only contain the first SFT in the pointed-to structure. But that should be a relatively simple fix. I dunno. The MEM has a very clear base, and a very clear offset, and a very clear size, it certainly LOOKS like it should be able to figure it out. Indeed. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #14 from rguenther at suse dot de 2007-11-07 15:05 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On Wed, 7 Nov 2007, dnovillo at google dot com wrote: Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On 7 Nov 2007 13:52:29 -, amacleod at redhat dot com [EMAIL PROTECTED] wrote: There is also an issue with partitioning, but it would then hide what I think is an important issue. Partitioning's problem is that it counts the number of items in the alias set and just uses that. There is only one entry for an entire SFT list, so it misses the other 819 in this particular list. The difficulty is determining how many of those SFTs are actually going to be relevant. Ideally, partitioning would share code with VOP processing so it can see exactly how many VOPs would be generated by each MEM. Agreed. The partitioner heuristics got severely skewed when we switched alias sets to only contain the first SFT in the pointed-to structure. But that should be a relatively simple fix. It actually contains all pointed-to SFTs. But yes, we should be able to fix this by conservatively counting VOPs (that is, rather overestimate). I plan to look at the heuristics as soon as we settled on a fix for the wrong-code PR33870. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #15 from dnovillo at google dot com 2007-11-07 15:14 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On 7 Nov 2007 15:05:57 -, rguenther at suse dot de [EMAIL PROTECTED] wrote: It actually contains all pointed-to SFTs. But yes, we should be able to fix this by conservatively counting VOPs (that is, rather overestimate). I plan to look at the heuristics as soon as we settled on a fix for the wrong-code PR33870. Remember that the partitioner cannot rely on VOPs. The very first time, they do not exist because aliases have not been computed and in subsequent passes the VOPs are many times stale because of aliasing changes. Blindly including VOPs the first time is not really workable because of the potentially huge number of them that we can generate. Prior to the partitioning scheme we used to have a scheme for trying to limit them with .GLOBAL_VAR (which now is only used when there are *no* global variables to prevent a corner case in TER). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #12 from amacleod at redhat dot com 2007-11-07 13:52 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 rguenther at suse dot de wrote: --- Comment #11 from rguenther at suse dot de 2007-11-06 21:36 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On Tue, 6 Nov 2007, amacleod at redhat dot com wrote: Partitioning doesn't really seem to be the root problem. But partitioning should exactly help avoiding this: There is also an issue with partitioning, but it would then hide what I think is an important issue. Partitioning's problem is that it counts the number of items in the alias set and just uses that. There is only one entry for an entire SFT list, so it misses the other 819 in this particular list. The difficulty is determining how many of those SFTs are actually going to be relevant. Ideally, partitioning would share code with VOP processing so it can see exactly how many VOPs would be generated by each MEM. looking at testcase-min.i: There are about 820 SFTs associated with the giant structure, and we decide that they *all* can be affected by the memory access and try to issue VOPS for them. 820 virtual operands should not happen because we have partitioning. this is true, but it is also true we should not be generating 820 vops for this particular stmt. An int is loaded via MEM[base: Hoopster_ptr_17, offset: 3552]. In get_tmr_operands(), we always call add_virtual_operands() with an offset of 0 and a size of -1. This seems wrong. we should be able to use the size of the load and offset information to figure out the right SFT(s) to add. Instead, because the size is -1, we simply include all of them. Is this offset of 0 and size of -1 to paper over something else? I understand there might be issues trying to get the right offset and base calculations under some conditions... I think TMR had not precise enough alias information that we did want to play safe here. In some cases (only constant offsets and strides) we might be able to optimize this. I dunno. The MEM has a very clear base, and a very clear offset, and a very clear size, it certainly LOOKS like it should be able to figure it out. The code in get_tmr_operands makes no attempt whatsoever to figure it out. It hard codes an offset of 0 and a size of -1 to add_virtual_operands, which is then forced to add all 820 virtual ops. Perhaps there are deeper issues, but ultimately, it would be nice to do that right thing here and try to pick the right SFT(s) if possible. That said, both problems do need to be addressed. Andrew -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #10 from amacleod at redhat dot com 2007-11-06 15:28 --- Partitioning doesn't really seem to be the root problem. looking at testcase-min.i: There are about 820 SFTs associated with the giant structure, and we decide that they *all* can be affected by the memory access and try to issue VOPS for them. An int is loaded via MEM[base: Hoopster_ptr_17, offset: 3552]. In get_tmr_operands(), we always call add_virtual_operands() with an offset of 0 and a size of -1. This seems wrong. we should be able to use the size of the load and offset information to figure out the right SFT(s) to add. Instead, because the size is -1, we simply include all of them. Is this offset of 0 and size of -1 to paper over something else? I understand there might be issues trying to get the right offset and base calculations under some conditions... -- amacleod at redhat dot com changed: What|Removed |Added Last reconfirmed|2007-08-14 08:44:16 |2007-11-06 15:28:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #11 from rguenther at suse dot de 2007-11-06 21:36 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On Tue, 6 Nov 2007, amacleod at redhat dot com wrote: Partitioning doesn't really seem to be the root problem. But partitioning should exactly help avoiding this: looking at testcase-min.i: There are about 820 SFTs associated with the giant structure, and we decide that they *all* can be affected by the memory access and try to issue VOPS for them. 820 virtual operands should not happen because we have partitioning. An int is loaded via MEM[base: Hoopster_ptr_17, offset: 3552]. In get_tmr_operands(), we always call add_virtual_operands() with an offset of 0 and a size of -1. This seems wrong. we should be able to use the size of the load and offset information to figure out the right SFT(s) to add. Instead, because the size is -1, we simply include all of them. Is this offset of 0 and size of -1 to paper over something else? I understand there might be issues trying to get the right offset and base calculations under some conditions... I think TMR had not precise enough alias information that we did want to play safe here. In some cases (only constant offsets and strides) we might be able to optimize this. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-05 22:32 --- Of course we should have partitioned those. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #7 from pranav dot bhandarkar at gmail dot com 2007-10-17
10:49 ---
Created an attachment (id=14362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14362action=view)
Reduced Testcase. Small Code, huge datastructure.
In the attached testcase due to an ivopts modification, while
rewriting the uses (rewrite_uses) the compiler crashes in tree-ssa-operands.c
because the memory required for the virtual operands of the modified stmt is
much greater than the thresholds controlled by OP_SIZE_{1,2,3} in
tree-ssa-operands.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-10-17 10:50 --- Adding Andrew here. -- pranav dot bhandarkar at gmail dot com changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2007-08-14 08:44 --- gfortran.dg/bound_2.f90 and gfortran.dg/common_resize_1.f trigger this ICE with -O --param avg-aliased-vops=100 -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-14 08:44:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2007-08-14 08:53 --- Created an attachment (id=14057) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14057action=view) reduced a bit from bound_2.f90 Correction, you actually need -O --param salias-max-array-elements=100 --param salias-max-implicit-fields=100 --param avg-aliased-vops=100 to trigger this ICE on these fortran tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 02:37 --- /* Fail if there is not enough space. If there are this many operands required, first make sure there isn't a different problem causing this many operands. If the decision is that this is OK, then we can specially allocate a buffer just for this request. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-10 02:57 ---
I think this is becuase we are looking into the static array variable's
initializers.
For an example:
static StgWord rY52_closure[] = { (W_)base_GHCziBase_ZC_static_info,
(W_)rY50_closure, (W_)base_GHCziBase_ZMZN_closure, 0x0 };
We add base_GHCziBase_ZC_static_info to the referenced variables but we
actually really don't reference it. This is a compile time hog and a memory
hog at the same time.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords||compile-time-hog, memory-hog
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #1 from tbm at cyrius dot com 2007-05-18 14:58 --- Created an attachment (id=13579) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13579action=view) preprocessed source delta's taking ages on this, so here's the current (large) code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #2 from tbm at cyrius dot com 2007-05-18 21:32 --- This appeared between 20070326 (works) and 20070422 (ICE). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
