This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wide-int, gimple

On Mon, Nov 25, 2013 at 12:24:30PM +0100, Richard Biener wrote:
> On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]