Remove build_int_cst_wide_type function.

[Anatoly Sokolov]

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.