Re: Remove build_int_cst_wide_type function.

["Anatoly Sokolov" <aesok at post dot ru>]

Hi.

----- Original Message ----- 
From: "Richard Guenther" <richard.guenther@gmail.com>
To: "Anatoly Sokolov" <aesok@post.ru>
Cc: <gcc-patches@gcc.gnu.org>; <java-patches@gcc.gnu.org>
Sent: Monday, May 10, 2010 1:33 PM
Subject: Re: Remove build_int_cst_wide_type function.


> > On Mon, May 10, 2010 at 11:24 AM, Anatoly Sokolov <aesok@post.ru> wrote:
> > Hi.
> >
> >
> > > Use build_int_cstu instead and retain using HOST_WIDE_INTs. Btw,
> > > both build_int_cst and build_int_cstu should do proper sign/zero
> > > extension as the types precision may be lower than that of
> > > HOST_WIDE_INT.
> >
> > The build_int_cst and build_int_cstu function don't clear extra bits
> > outside
> > of the type precision. The build_int_ct_type function truncate signed
> > HOST_WIDE_INT constant to the type precision. Comment before
> > build_int_cst_type
> > say:
> > /* ... Constants
> > with these extra bits may confuse the fold so that it detects overflows
> > even in cases when they do not occur, and in general should be avoided.
> > We cannot however make this a default behavior of build_int_cst without
> > more intrusive changes, since there are parts of gcc that rely on the 
> > extra
> > precision of the integer constants. */
> >
> > Consequently, need both build_int_cst and build_int_cstu functions which
> > don't truncate constant and new build_int_cstu_type function which 
> > truncate
> > unsigned HOST_WIDE_INT constants.
> >
> > How about rename build_int_cst_type/build_int_cstu_type function to
> > hwi_to_tree/uhwi_to_tree by analogy with the double_int_to_tree function?
>
> I don't think the comment is valid.  The problem is that INTEGER_CSTs
> are shared and non-canonical ones should never be entered into the
> shared pool.  Which means that build_int_cst_wide should assert
> that the constant is properly zero-/sign-extended according to its
> type (at least with ENABLE_CHECKING).  Currently build_int_cst_wide
> is used as an optimization (to avoid the zero-/sign-extension when its
> already done), but really it is the low-level interface that shouldn't
> be exposed ... (we have way too many ways to build INTEGER_CSTs...)

Hence, build_int_cst_type/build_int_cstu_type function should truncate
constants to the type precision and build_int_cst_type should be removed?

Can I remame build_int_cst/build_int_cstu functions to 
hwi_to_tree/uhwi_to_tree?

Anatoly.