wide-int, gimple

Mike Stump mikestump@comcast.net
Thu Jan 2 04:10:00 GMT 2014

On Nov 28, 2013, at 6:20 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> On Thu, Nov 28, 2013 at 12:58 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Jakub Jelinek <jakub@redhat.com> writes:
>>> On Mon, Nov 25, 2013 at 12:24:30PM +0100, Richard Biener wrote:
>>>> On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump <mikestump@comcast.net> wrote:
>>>>> Richi has asked the we break the wide-int patch so that the
>>>>> individual port and front end maintainers can review their parts
>>>>> without have to go through the entire patch.  This patch covers the
>>>>> gimple code.
>>>> @@ -1754,7 +1754,7 @@ dump_ssaname_info (pretty_printer *buffer, tree
>>>> node, int spc)
>>>>   if (!POINTER_TYPE_P (TREE_TYPE (node))
>>>>       && SSA_NAME_RANGE_INFO (node))
>>>>     {
>>>> -      double_int min, max, nonzero_bits;
>>>> +      widest_int min, max, nonzero_bits;
>>>>       value_range_type range_type = get_range_info (node, &min, &max);
>>>>       if (range_type == VR_VARYING)
>>>> this makes me suspect you are changing SSA_NAME_RANGE_INFO
>>>> to embed two max wide_ints.  That's a no-no.
>>> Well, the range_info_def struct right now contains 3 double_ints, which is
>>> unnecessary overhead for the most of the cases where the SSA_NAME's type
>>> has just at most HOST_BITS_PER_WIDE_INT bits and thus we could fit all 3 of
>>> them into 3 HOST_WIDE_INTs rather than 3 double_ints.  So supposedly struct
>>> range_info_def could be a template on the type's precision rounded up to HWI
>>> bits, or say have 3 alternatives there, use
>>> FIXED_WIDE_INT (HOST_BITS_PER_WIDE_INT) for the smallest types,
>>> FIXED_WIDE_INT (2 * HOST_BITS_PER_WIDE_INT) aka double_int for the larger
>>> but still common ones, and widest_int for the rest, then the API to set/get
>>> it could use widest_int everywhere, and just what storage we'd use would
>>> depend on the precision of the type.
>> This patch adds a trailing_wide_ints <N> that can be used at the end of
>> a variable-length structure to store N wide_ints.  There's also a macro
>> to declare get/set methods for each of the N elements.
>> At the moment I've only defined non-const operator[].  It'd be possible
>> to add a const version later if necessary.
>> The size of range_info_def for precisions that fit in M HWIs is then
>> 1 + 3 * M, so 4 for the common case (down from 6 on trunk).  The maximum
>> is 7 for current x86_64 types (up from 6 on trunk).
>> I wondered whether to keep the interface using widest_int, but I think
>> wide_int works out more naturally.  The only caller that wants to extend
>> beyond the precision is CCP, but that's already special because the upper
>> bits are supposed to be set (i.e. it's not a normal sign or zero extension).
>> This relies on the SSA_NAME_ANTI_RANGE_P patch I just posted.
>> If this is OK I'll look at using the same structure elsewhere.
> Looks good to me.

So, is that an Ok for the gimple patch and the follow on work?  Just double checking.

More information about the Gcc-patches mailing list