On Nov 28, 2013, at 6:20 AM, Richard Biener <richard.guent...@gmail.com> wrote:
> On Thu, Nov 28, 2013 at 12:58 PM, Richard Sandiford
> <rdsandif...@googlemail.com> wrote:
>> Jakub Jelinek <ja...@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 <mikest...@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.
