This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR28268, ICE building vector const { 1, 1 }


On Thu, 6 Jul 2006, Ian Lance Taylor wrote:

> Richard Guenther <rguenther@suse.de> writes:
> 
> > *************** fold_convert (tree type, tree arg)
> > *** 2084,2091 ****
> >   	}
> >   
> >       case VECTOR_TYPE:
> > !       if (integer_zerop (arg))
> > ! 	return build_zero_vector (type);
> >         gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
> >         gcc_assert (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig)
> >   		  || TREE_CODE (orig) == VECTOR_TYPE);
> > --- 2084,2092 ----
> >   	}
> >   
> >       case VECTOR_TYPE:
> > !       if (integer_zerop (arg)
> > ! 	  || integer_onep (arg))
> > ! 	return build_cst_vector (type, arg);
> >         gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
> >         gcc_assert (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig)
> >   		  || TREE_CODE (orig) == VECTOR_TYPE);
> 
> This makes me uncomfortable.  The number zero seems like a special
> case which merits special handling.  The number one does not.  What
> you are looking for is a function which returns the multiplicative
> identity for TYPE.  Currently you are getting it by calling
> fold_convert (TYPE, integer_one_node).  Suppose you write the
> multiplicative identify function, and handle VECTOR_TYPE there, rather
> than making the number one a special case in fold_convert?
> 
> Otherwise I think you need to give some justification for why
> fold_convert should not permit any constant for VECTOR_TYPE.  And it's
> hard to see what that justification should be.

My reasoning was that as zero (identity for addition), one is a special 
number (identity for multiplication).  There's one other special number
that one could add, -1, which represents a "sign", but that stretches
the argument a bit.

The other fix I was thinking about is simply punting on VECTOR_TYPE
arguments completely for the optimizations in fold_plusminus_mult_expr.

Now there's some item on my TODO list to provide generic build_zero 
(type) and build_one (type) functions and rip out the int -> real
and int -> vector conversions from fold_convert.  At least we had
in the past the casual errors of using integer_zero_node where we
really wanted build_zero (type) and now are forced to use fold_convert
if not spelling out all handled types explicitly.  Though TODO and
not really appropriate for stage3.

(now, one could fold build_cst_vector into its only user, fold_convert,
to avoid introducing more users of that function)

Thanks,
Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]