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

2017-11-08 Thread Richard Biener
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: On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Tue, Oct 24,

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

2017-11-08 Thread Richard Sandiford
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: Richard Biener writes: > On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford > wrote: >> Richard Bie

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

2017-10-25 Thread Richard Biener
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: On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Tue, Oct 24,

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

2017-10-25 Thread Richard Sandiford
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: Richard Biener writes: > On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford > wrote: >> Eric Botcaz

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

2017-10-25 Thread Jakub Jelinek
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 is

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

2017-10-25 Thread Richard Biener
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: On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford wrote: > Eric Botcazou writes: >>> Yeah. E.g. for

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

2017-10-24 Thread Richard Sandiford
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: Eric Botcazou writes: >> Yeah. E.g. for ==, the two options would be: >> >> a) must_eq (a, b) ->

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

2017-10-24 Thread Richard Biener
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: > Yeah. E.g. for ==, the two options would be: > > a) must_eq (a, b) -> a == b >must_ne (a, b) ->

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

2017-10-24 Thread Richard Sandiford
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 must_ne (a, b) -> a != b which has the weird property that (a == b) != (

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

2017-10-24 Thread Richard Biener
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 that (a == b) != (!(a != b)) >>> >>> b) must_eq (a, b

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

2017-10-24 Thread Richard Sandiford
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 != b >> >>which has

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

2017-10-24 Thread Eric Botcazou
> 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

2017-10-24 Thread Richard Sandiford
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 in a particular way. E.

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

2017-10-24 Thread Eric Botcazou
> 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

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

2017-10-23 Thread Richard Sandiford
This series adds support for offsets and sizes that are a runtime invariant rather than a compile time constant. It's based on the patch posted here: https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00406.html The rest of the covering note is split into: - Summary (from the message linked abov