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

On Wed, Nov 8, 2017 at 10:39 AM, Richard Sandiford wrote: > Richard Biener writes: >> On Wed, Oct 25, 2017 at 1:26 PM, Richard Sandiford >> wrote: >>> Richard Biener writes:

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

Richard Biener writes: > On Wed, Oct 25, 2017 at 1:26 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford >>> wrote:

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

On Wed, Oct 25, 2017 at 1:26 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford >> wrote: >>> Richard Biener writes:

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

Richard Biener writes: > On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford >>> wrote:

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

On Wed, Oct 25, 2017 at 12:19:37PM +0200, Richard Biener wrote: > Hum. But then we still warn for must_eq_p (x, 1), no? > > So why does > > int f (unsigned int x) > { > return x != 0; > } > > not warn? Probably because of promotion of the arg. Because then one comparison operand

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

On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford >> wrote: >>> Richard Biener writes:

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

Richard Biener writes: > On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford >>> wrote:

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

On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford >> wrote: >>> Eric Botcazou writes: >

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

Richard Biener writes: > On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford > wrote: >> Eric Botcazou writes: Yeah. E.g. for ==, the two options would be: a) must_eq (a, b) -> a == b

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

On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford wrote: > Eric Botcazou 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

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

Eric Botcazou 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

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

> 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

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

Eric Botcazou 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

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

> 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