This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [000/nnn] poly_int: representation of runtime offsets and sizes
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Sandiford <richard dot sandiford at linaro dot org>
- Date: Tue, 24 Oct 2017 14:09:13 +0200
- Subject: Re: [000/nnn] poly_int: representation of runtime offsets and sizes
- Authentication-results: sourceware.org; auth=none
- References: <871sltvm7r.fsf@linaro.org> <4728974.295PUQgt1k@polaris> <87o9owq35v.fsf@linaro.org> <10524871.8B8OuvVQlb@polaris> <87fua8pz6v.fsf@linaro.org>
On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Eric Botcazou <ebotcazou@adacore.com> writes:
>>> 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
>>
>> Yes, a) was the one I had in mind, i.e. the traditional operators are the must
>> variants and you use an outer ! in order to express the may. Of course this
>> would require a bit of discipline but, on the other hand, if most of the cases
>> fall in the must category, that could be less ugly.
>
> I just think that discipline is going to be hard to maintain in practice,
> since it's so natural to assume (a == b || a != b) == true. With the
> may/must approach, static type checking forces the issue.
>
>>> Sorry about that. It's the best I could come up with without losing
>>> the may/must distinction.
>>
>> Which variant is known_zero though? Must or may?
>
> must. maybe_nonzero is the may version.
Can you rename known_zero to must_be_zero then? What's wrong with
must_eq (X, 0) / may_eq (X, 0) btw?
Richard.
> Thanks,
> Richard