Re: Remove build_int_cst_wide_type function.

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, May 10, 2010 at 12:24 PM, Anatoly Sokolov <aesok@post.ru> wrote:
> 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?

Yes.  Assuming that it works of course - if the comment is
indeed correct and some code expects to build non-canonical
integer-csts that code should probably use double_ints
directly instead of creating trees.  Likely the excess precision
will be for intermediate results only.

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

Hmm - there are a lot of calls to these, I'd prefer to leave them
as is for now.  If we can make build_int_cst_wide local to tree.c
then maybe - it would be a consistent iterface.  But as long
as that stays I see no reason to do it now.

Thanks,
Richard.

> Anatoly.
>
>
>