[Bug tree-optimization/31976] New: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3

[Bug tree-optimization/31976] New: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3

[tbm at cyrius dot com]

I'm getting the following ICE with gcc 4.3 20060515 and -O3:

(sid)24074:tbm@em64t: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O3 838.c
838.c: In function 'rPIc_entry':
838.c:3181: internal compiler error: in ssa_operand_alloc, at
tree-ssa-operands.c:487
Please submit a full bug report, ...

I'm currently reducing it.  I'll attach a testcase later.


-- 
           Summary: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-
                    operands.c:487 with -O3
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tbm at cyrius 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

[tbm at cyrius dot com]

------- 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=13579&action=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

[tbm at cyrius dot com]

------- 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

[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3

[pinskia at gcc dot gnu dot org]

------- 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

[pinskia at gcc dot gnu dot org]

------- 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

[mmitchel at gcc dot gnu dot org]

-- 

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

[belyshev at depni dot sinp dot msu dot ru]

------- 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|0000-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

[belyshev at depni dot sinp dot msu dot ru]

------- 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=14057&action=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

[pranav dot bhandarkar at gmail dot com]

------- 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=14362&action=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

[pranav dot bhandarkar at gmail dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[amacleod at redhat dot com]

------- 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

[rguenther at suse dot de]

------- 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

[amacleod at redhat dot com]

------- 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

[dnovillo at google dot com]

------- 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 -0000, amacleod at redhat dot com
<gcc-bugzilla@gcc.gnu.org> 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

[rguenther at suse dot de]

------- 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 -0000, amacleod at redhat dot com
> <gcc-bugzilla@gcc.gnu.org> 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

[dnovillo at google dot com]

------- 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 -0000, rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> 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

[rguenth at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=131257
Log:
2008-01-02  Richard Guenther  <rguenther@suse.de>

        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