Re: RFA: Fix value-prof.c call to build_int_cst_wide

[Richard Sandiford <rsandifo at redhat dot com>]

Paul Schlie <schlie@comcast.net> writes:
>> or when HOST_BITS_PER_WIDE_INT != 32 ;)  (Because build_int_cst_wide
>> expects HOST_WIDE_INTs.)
>> ...
>>    tree_val = build_int_cst_wide (get_gcov_type (),
>> -                                val & 0xffffffffull, val >> 32);
>> +                                (unsigned HOST_WIDE_INT) val,
>> +                                val >> (HOST_BITS_PER_WIDE_INT - 1) >> 1);
>
> Sorry, I'm a bit confused; when building an expression for evaluation on a
> target, shouldn't all the operations be based solely on the attributes of
> that target's variable type, not the host's?  (i.e. what does an arbitrary
> host's HOST_WIDE_INT precision have to do with a target expression operand
> precision?) 

Sorry, I don't understand your objection.  Have you looked at how
integers are represented at the tree level?  They're represented
as pairs of HOST_WIDE_INTs: a low integer and a high integer.
build_int_cst_wide() returns an INTEGER_CST for such a pair.

Ah, I see the comments in tree.def are a bit out of date:

    /* Contents are in TREE_INT_CST_LOW and TREE_INT_CST_HIGH fields,
       32 bits each, giving us a 64 bit constant capability.  INTEGER_CST
       nodes can be shared, and therefore should be considered read only.
       They should be copied, before setting a flag such as
       TREE_OVERFLOW.  If an INTEGER_CST has TREE_OVERFLOW or
       TREE_CONSTANT_OVERFLOW already set, it is known to be unique.
       INTEGER_CST nodes are created for the integral types, for pointer
       types and for vector and float types in some circumstances.  */
    DEFTREECODE (INTEGER_CST, "integer_cst", tcc_constant, 0)

"32 bits" should be "HOST_BITS_PER_WIDE_INT bits" and "64 bits"
should be "HOST_BITS_PER_WIDE_INT * 2 bits".  Is that what's
confusing you?

Richard