Re: [000/nnn] poly_int: representation of runtime offsets and sizes

[Richard Sandiford <richard dot sandiford at linaro dot org>]

Eric Botcazou <ebotcazou@adacore.com> writes:
>> The patch that adds poly_int has detailed documentation, but the main
>> points are:
>> 
>> * there's no total ordering between poly_ints, so the best we can do
>>   when comparing them is to ask whether two values *might* or *must*
>>   be related in a particular way.  E.g. if mode A has size 2 + 2X
>>   and mode B has size 4, the condition:
>> 
>>     GET_MODE_SIZE (A) <= GET_MODE_SIZE (B)
>> 
>>   is true for X<=1 and false for X>=2.  This translates to:
>> 
>>     may_le (GET_MODE_SIZE (A), GET_MODE_SIZE (B)) == true
>>     must_le (GET_MODE_SIZE (A), GET_MODE_SIZE (B)) == false
>> 
>>   Of course, the may/must distinction already exists in things like
>>   alias analysis.
>
> I presume that you considered using traditional operators instead of awkward 
> names, despite the lack of total ordering, and rejected it?

Yeah.  E.g. for ==, the two options would be:

a) must_eq (a, b)   -> a == b
   must_ne (a, b)   -> a != b

   which has the weird property that (a == b) != (!(a != b))

b) must_eq (a, b)   -> a == b
   may_ne (a, b)    -> a != b

   which has the weird property that a can be equal to b when a != b

may/must matters in a similar way as it does for alias analysis:
"may" usually selects conservatively-correct, just-in-case behaviour
while "must" selects something that would be wrong if the condition
didn't hold.

> Because:
>
> -      && (bitpos == 0 || MEM_P (target)))
> +      && (known_zero (bitpos) || MEM_P (target)))
>
> -             && bitsize == TYPE_PRECISION (type))
> +             && must_eq (bitsize, TYPE_PRECISION (type)))
>
> -       if (need_to_clear && size > 0)
> +       if (need_to_clear && may_gt (size, 0))
>
> is really ugly...

Sorry about that.  It's the best I could come up with without losing
the may/must distinction.

Thanks,
Richard