search for: max_int

...ng und 31.03.2009 Berechnung<-as.Date("22.01.2009","%d.%m.%Y") Enddatum<-as.Date("31.03.2009","%d.%m.%Y") Tage<-difftime(Enddatum, Berechnung) Tage<-as.numeric(substr(format(Tage),1,2)) #maximal interessierend sind 100 Tage (4 Monate)-Differenzen max_int<-82 Tage<-max_int max_bob<-82 varnames<-paste("st_rendite_",seq(max_int),sep="") analyse<-rnorm(10000) for(i in 1:min(max_bob,max_int)){ assign(varnames[i],diff(log(analyse),i)*100) } #Wurzel_t - Approximation ?berpr?fen varianzen<-paste("var_",se...

...is how poison differs from undef. > > I will second this request for much the same reason. > undef isn't strong enough to perform the simplification "a + 1 > a --> true" for an nsw add. If we use undef instead of poison, "a + 1" will produce undef iff a is MAX_INT, but we cannot choose a bit-pattern for the undef result that is greater than MAX_INT. In other words, as David said, the comparison "icmp gt i32 undef, MAX_INT" is always true, just as "and i32 undef, 0" always produces 0. I've been discussing a model with David that migh...

Hi, I am trying to understand the limitations of the current vectorizer, and came upon these test cases that fail to get vectorized. 1. loop1 below (note the increment by 2) fails to get vectorized because the access a[j+1] is considered to wrap around (the corresponding SCEV doesn't have nsw/nuw set) and hence isStridedPtr() in LoopAccessAnalysis.cpp return false. #define SIZE 100000 void

...e is): we can have dependency between SCEVs which is not represented in use-list. For example: if ({100,+,1} > -1) { x = a / {1,+,1} } If we prove nsw for the first addrec, it will also imply nsw for the second addrec (because the number of iterations in this loop is provably less than MAX_INT - 99). But there is no clear use-chain dependency between them. So I would rather belive in option 1 as in the most reliable. I'll try to experiment with options 1 and 3 and see where it gets us. Best regards, Max -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpoint...

...mple, "add nsw i8" can > produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit > bitpattern. This is strong enough to do things like "a + 1 > a --> true", > because on overflow of "a + 1" we can choose an poison value of "MAX_INT + > 1", even though that is not a valid i8 bit pattern. > > So, a short version would be that poison is like undef, except you get to > include the overflow bits of the computation in your undef value. I suspect it will be hard to justify reg2mem is meaning preserving in this sch...

...erent problem related to this late flag setting. The problem is that current SCEV implementation caches a lot of data about SCEVs. In particular, information about ranges and loop backedge taken counts. A side effect of that is that if we had an AddRec like {1,+,1} and cached its range as [MIN_INT, MAX_INT+1), and then later found out that this recurrency provably has <nsw>, its cached range doesn't get updated. As well as ranges of all other SCEVs that depend on that. As result, we have a very weird behavior of SCEV that is unable to prove that sext({1,+,1}<nsw>) is a positive value...

...y between SCEVs which is not represented in use-list. For example: > > if ({100,+,1} > -1) { > x = a / {1,+,1} > } > > If we prove nsw for the first addrec, it will also imply nsw for the second addrec (because the number of iterations in this loop is provably less than MAX_INT - 99). But there is no clear use-chain dependency between them. So I would rather belive in option 1 as in the most reliable. That's true, but that's also not the problem that this thread intends to solve. I think option 1 is fine, but (3) has greater applicability. For instance, if we h...

...y) /* Write logging setup. */ @@ -127,6 +127,21 @@ struct vhost_memory { /* Set eventfd to signal an error */ #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) +/* Query upper limit on nregions in VHOST_SET_MEM_TABLE arguments. + * Returns: + * 0 < value <= MAX_INT - gives the upper limit, higher values will fail + * 0 - there's no static limit: try and see if it works + * -1 - on failure + */ +#define VHOST_GET_MEM_MAX_NREGIONS _IO(VHOST_VIRTIO, 0x23) + +/* Returned by VHOST_GET_MEM_MAX_NREGIONS to mean there's no static limit: + * try and it'...

...y) /* Write logging setup. */ @@ -127,6 +127,21 @@ struct vhost_memory { /* Set eventfd to signal an error */ #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) +/* Query upper limit on nregions in VHOST_SET_MEM_TABLE arguments. + * Returns: + * 0 < value <= MAX_INT - gives the upper limit, higher values will fail + * 0 - there's no static limit: try and see if it works + * -1 - on failure + */ +#define VHOST_GET_MEM_MAX_NREGIONS _IO(VHOST_VIRTIO, 0x23) + +/* Returned by VHOST_GET_MEM_MAX_NREGIONS to mean there's no static limit: + * try and it'...

...d to this late flag > setting. The problem is that current SCEV implementation caches a lot of > data about SCEVs. In particular, information about ranges and loop backedge > taken counts. A side effect of that is that if we had an AddRec like {1,+,1} > and cached its range as [MIN_INT, MAX_INT+1), and then later found out that > this recurrency provably has <nsw>, its cached range doesn't get updated. As > well as ranges of all other SCEVs that depend on that. As result, we have a > very weird behavior of SCEV that is unable to prove that sext({1,+,1}<nsw>) >...

...uot; can >>> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >>> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >>> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >>> 1", even though that is not a valid i8 bit pattern. >>> >>> So, a short version would be that poison is like undef, except you get to >>> include the overflow bits of the computation in your undef value. >> >> I suspect it will be hard to...

...add nsw i8" can >> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >> 1", even though that is not a valid i8 bit pattern. >> >> So, a short version would be that poison is like undef, except you get to >> include the overflow bits of the computation in your undef value. > > I suspect it will be hard to justify reg2mem is mea...

...vhost_memory { > > /* Set eventfd to signal an error */ > > #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) > > > > +/* Query upper limit on nregions in VHOST_SET_MEM_TABLE arguments. > > + * Returns: > > + * 0 < value <= MAX_INT - gives the upper limit, higher values will fail > > + * 0 - there's no static limit: try and see if it works > > + * -1 - on failure > > + */ > > +#define VHOST_GET_MEM_MAX_NREGIONS _IO(VHOST_VIRTIO, 0x23) > > + > > +/* Returned by VHOST_GET_MEM_MAX_NREG...

...vhost_memory { > > /* Set eventfd to signal an error */ > > #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) > > > > +/* Query upper limit on nregions in VHOST_SET_MEM_TABLE arguments. > > + * Returns: > > + * 0 < value <= MAX_INT - gives the upper limit, higher values will fail > > + * 0 - there's no static limit: try and see if it works > > + * -1 - on failure > > + */ > > +#define VHOST_GET_MEM_MAX_NREGIONS _IO(VHOST_VIRTIO, 0x23) > > + > > +/* Returned by VHOST_GET_MEM_MAX_NREG...

On 01/28/2015 07:02 AM, Sean Silva wrote: > Could you maybe provide an example where replacing `%always_poison` > with `undef` will change the meaning? At least for me, the thing that > I'm most unclear about is how poison differs from undef. I will second this request for much the same reason. > > -- Sean Silva > > On Wed, Jan 28, 2015 at 2:50 AM, David Majnemer >

...;>>> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >>>> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >>>> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >>>> 1", even though that is not a valid i8 bit pattern. >>>> >>>> So, a short version would be that poison is like undef, except you get to >>>> include the overflow bits of the computation in your undef value. >>> >>> I s...

...;> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >>>>> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >>>>> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >>>>> 1", even though that is not a valid i8 bit pattern. >>>>> >>>>> So, a short version would be that poison is like undef, except you get to >>>>> include the overflow bits of the computation in your undef value. >>>>...

...erent problem related to this late flag setting. The problem is that current SCEV implementation caches a lot of data about SCEVs. In particular, information about ranges and loop backedge taken counts. A side effect of that is that if we had an AddRec like {1,+,1} and cached its range as [MIN_INT, MAX_INT+1), and then later found out that this recurrency provably has <nsw>, its cached range doesn't get updated. As well as ranges of all other SCEVs that depend on that. As result, we have a very weird behavior of SCEV that is unable to prove that sext({1,+,1}<nsw>) is a positive value...

...l an error */ > > > > #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) > > > > > > > > +/* Query upper limit on nregions in VHOST_SET_MEM_TABLE arguments. > > > > + * Returns: > > > > + * 0 < value <= MAX_INT - gives the upper limit, higher values will fail > > > > + * 0 - there's no static limit: try and see if it works > > > > + * -1 - on failure > > > > + */ > > > > +#define VHOST_GET_MEM_MAX_NREGIONS _IO(VHOST_VIRTIO, 0x23) > > > >...

...l an error */ > > > > #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) > > > > > > > > +/* Query upper limit on nregions in VHOST_SET_MEM_TABLE arguments. > > > > + * Returns: > > > > + * 0 < value <= MAX_INT - gives the upper limit, higher values will fail > > > > + * 0 - there's no static limit: try and see if it works > > > > + * -1 - on failure > > > > + */ > > > > +#define VHOST_GET_MEM_MAX_NREGIONS _IO(VHOST_VIRTIO, 0x23) > > > >...