On Thu, Jan 2, 2014 at 5:10 AM, Mike Stump <mikest...@comcast.net> wrote:
> 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.
Yes.
