On Mon, Nov 25, 2013 at 09:16:24PM +0000, Richard Sandiford wrote:
> > 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.
>
> Would it make sense to just use trees for the min and max?
Note, we don't have just min/max, but also nonzero_bits.
Anyway, I don't think that is a good idea, you can fairly often end up with
values that can't be shared with something else, and the overhead of
INTEGER_CST is quite large then.
range_info_def could very well be just struct with HOST_WIDE_INT flexible
array member or just array of HOST_WIDE_INTs, all the routines that care
about the internal details of the representation are in tree-ssanames.c
- [sg]et_range_info, [sg]et_nonzero_bits and
duplicate_ssa_name_range_info/duplicate_ssa_name_fn. All of those
work solely for INTEGRAL_TYPE_P tree types of SSA_NAMEs, and all the
functions have access to the SSA_NAME from which you can find out the
precision.
Jakub
