http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-20
12:55:10 UTC ---
(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.
