[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7

[razya at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471

--- Comment #4 from razya at il dot ibm.com 2011-06-20 14:14:13 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Why is
> > >   D.7313_5 = MEM[(struct  *).paral_data_param_1(D)].D.7288; /*  Number of loop
> > > iterations.  */
> > > of type __int128?  That looks bogus.
> > 
> > the size of 128 was determined according to the precision of the ivs in
> > canonicalize_loop_ivs:
> > 
> > canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
> > {
> >   unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit));   
> >   for (psi = gsi_start_phis (loop->header);         
> >        !gsi_end_p (psi); gsi_next (&psi))
> >     {
> >       gimple phi = gsi_stmt (psi);
> >       tree res = PHI_RESULT (phi);
> > 
> >       if (is_gimple_reg (res) && TYPE_PRECISION (TREE_TYPE (res)) > precision)
> >         precision = TYPE_PRECISION (TREE_TYPE (res));
> >     }
> > 
> >   type = lang_hooks.types.type_for_size (precision, 1); // precision == 128 
> >   ...
> >  }
> > 
> > Does it seem that the precision should not determine the new type size, or that 
> > the precision itself being 128 is strange?
> Well, autopar seems to introduce this 128 bit type in the first place,
> and I wonder why it does that.  And it definitely should avoid doing this.

What happens is that autopar calls canonicalize_loop_ivs() when it is starting
to change the loop.

Here's a  part of the documentation of canonicalize_loop_ivs(): 

 "  When the IV type precision has to be larger
   than *NIT type precision, *NIT is converted to the larger type, the
   conversion code is inserted before the loop, and *NIT is updated to
   the new definition.  "  

In this case of cactusADM, one of the loop's IVs indeed has a precision of 128,
and therefore a conversion to a type of 128 bit is created.

I checked the precision of the loop's IVs a few passes before autopar, and even
when I disable autopar, and indeed there is an IV that has a type with 128
precision.