Re: Remove build_int_cst_wide_type function.

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

On Mon, May 10, 2010 at 1:17 PM, Anatoly Sokolov <aesok@post.ru> wrote:
>
> ----- 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 2:34 PM
> Subject: Re: Remove build_int_cst_wide_type function.
>
>
>>> 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.
>>
>
> The build_int_cstu used 24 times only. The build_int_cst used 876 times, but
> in most uses in get NULL_TREE as fitst argument that forces to do checks in
> the build_int_cst ?function:
> ...
> ?/* Support legacy code. ?*/
> ?if (!type)
> ? type = integer_type_node;
> ...
>
> If change NULL_TREE to integer_type_node in all calls the build_int_cst
> function then ?build_int_cst may be simplified to inline function:
>
> static inline tree
> build_int_cst/shwi_to_tree (tree type, HOST_WIDE_INT low)
> {
> ?return double_int_to_tree (type, shwi_to_double_int (low));
> }
>
> I.e., can do two changes for the cost of one.

The callers with NULL type should probably be reviewed separately.
Some of them might want to use the simpler size_int interface
(even if that changes the type from integer_type_node to
size_type_node).  Some obvious ones indeed explicitly want
integer_type_node.

Lumping both changes together will make it hard to track down
those persisting errors.  NULL_TREE at least tells us that this
is a suspicious case.

Richard.

> Anatoly.
>