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.
