> > Yeah, I think the other comment should be adjusted accordingly. I
> > didn't remember we have that one extra bit either ... ;) (given wide-ints
> > have unsigned variants of ops I wonder if it is really necessary, but who
> > knows - the wide-int rep w/o a sign is really sth odd and I blame R
> On Wed, 6 Jul 2016, Jan Hubicka wrote:
>
> > > Jan Hubicka writes:
> > >
> > > > Bootstrapped/regtested x86_64-linux, OK?
> > > >
> > > > * gcc.dg/tree-ssa/scev-14.c: new testcase.
> > >
> > > FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump-not ivopts "Overflowness
> > > wrto loop nit
On Wed, 6 Jul 2016, Jan Hubicka wrote:
> > Jan Hubicka writes:
> >
> > > Bootstrapped/regtested x86_64-linux, OK?
> > >
> > > * gcc.dg/tree-ssa/scev-14.c: new testcase.
> >
> > FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump-not ivopts "Overflowness
> > wrto loop niter:\tOverflow"
>
> Aha, t
> Jan Hubicka writes:
>
> > Bootstrapped/regtested x86_64-linux, OK?
> >
> > * gcc.dg/tree-ssa/scev-14.c: new testcase.
>
> FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump-not ivopts "Overflowness wrto
> loop niter:\tOverflow"
Aha, this is wrong version of testcase. The scan-tree-dump-not d
Jan Hubicka writes:
> Bootstrapped/regtested x86_64-linux, OK?
>
> * gcc.dg/tree-ssa/scev-14.c: new testcase.
FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump-not ivopts "Overflowness wrto
loop niter:\tOverflow"
$ grep Overflowness scev-14.c.155t.ivopts
Overflowness wrto loop niter: No-
Richard Biener writes:
> On Tue, 5 Jul 2016, Jan Hubicka wrote:
>
>> > On Tue, 5 Jul 2016, Richard Biener wrote:
>> >
>> > >given widest_int has only precision of TImode on x86_64?
>> >
>> > Is that the case? The comments say:
>> >
>> > It is really finite precision math where the precisio
On Tue, 5 Jul 2016, Jan Hubicka wrote:
> > On Tue, 5 Jul 2016, Richard Biener wrote:
> >
> > >given widest_int has only precision of TImode on x86_64?
> >
> > Is that the case? The comments say:
> >
> > It is really finite precision math where the precision is 4 times the
> > size of
> On Tue, 5 Jul 2016, Richard Biener wrote:
>
> >given widest_int has only precision of TImode on x86_64?
>
> Is that the case? The comments say:
>
> It is really finite precision math where the precision is 4 times the
> size of the largest integer that the target port can represent.
>
> This can overflow for __uint128_t IV iterating to UINT128_MAX I think
> given widest_int has only precision of TImode on x86_64? An
> after-the-fact check like
>
>if (nit == 0)
> return true;
>
> does the trick I guess.
OK, I suppose we need to review niter and related code for s
On Tue, 5 Jul 2016, Richard Biener wrote:
given widest_int has only precision of TImode on x86_64?
Is that the case? The comments say:
It is really finite precision math where the precision is 4 times the
size of the largest integer that the target port can represent.
And the targe
On Sun, 3 Jul 2016, Jan Hubicka wrote:
> Hi,
> this is updated version of patch. I finally convinced myself to read bit of
> wide-int.h and learnt some new things, like that they exists in multiple
> precisions. I always tought of wide-int as wider version of HOST_WIDE_INT
> that
> can hold all
Hi,
this is updated version of patch. I finally convinced myself to read bit of
wide-int.h and learnt some new things, like that they exists in multiple
precisions. I always tought of wide-int as wider version of HOST_WIDE_INT that
can hold all of target data types with not-so handy API because it
> > Index: tree-scalar-evolution.c
> > ===
> > --- tree-scalar-evolution.c (revision 237856)
> > +++ tree-scalar-evolution.c (working copy)
> > @@ -280,6 +280,7 @@ along with GCC; see the file COPYING3.
> > #include "params.h"
> > #i
On Thu, 30 Jun 2016, Jan Hubicka wrote:
> Hi,
> i sent the email before, but it seems it never left my machine. Sorry for
> possible duplicates. This is updated version which does not overflow (by
> capping nit), but still using widest_int for the calculatoins. It seems more
> readable to do so t
Hi,
i sent the email before, but it seems it never left my machine. Sorry for
possible duplicates. This is updated version which does not overflow (by
capping nit), but still using widest_int for the calculatoins. It seems more
readable to do so than using wi:add/wi:mult/wi:lt and overflow checks,
Hi,
after some exprimentation I am re-testing the following version. wide_int
variant
seemed ugly. Here I simply cap nit to be in range of the type and then the
widest_int calculation ought to be safe.
What do you think? Perhaps I need to use signs of STEP and BASE type just in
the case some cas
On Wed, 29 Jun 2016, Jan Hubicka wrote:
> > + if (!get_max_loop_iterations (loop, &nit))
> > +/* 10GHz CPU runing one cycle loop will reach 2^60 iterations in 260
> > + years. I won't live long enough to be forced to fix the
> > + miscompilation. Having the limit here will let u
> + if (!get_max_loop_iterations (loop, &nit))
> +/* 10GHz CPU runing one cycle loop will reach 2^60 iterations in 260
> + years. I won't live long enough to be forced to fix the
> + miscompilation. Having the limit here will let us to consider
> + 64bit IVs with base 0 and
On Mon, 27 Jun 2016, Jan Hubicka wrote:
> Hi,
> this patch makes simple_iv to determine more often that IV can not overflow.
> First I commonized the logic in simple_iv with nowrap_type_p because it tests
> the same. Second I added iv_can_overflow_p which uses known upper bound on
> number of iter
19 matches
Mail list logo
