On Mon, Jan 26, 2015 at 7:06 AM, Richard Biener wrote:
>
> This is the 2nd thing I came up with after looking at PR64277.
> VRP does a poor job computing value-ranges of unrolled loop IVs
> thus a very simple thing to do is to factor in previous VRP results
> by intersecting what VRP2 computes wit
Richard Biener wrote:
> On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> > Then it probably should be ok. I'm really afraid of emitting more warnings
> > with such high false positive rate now.
>
> As the patch also mitigates some of the code bloat we get with
> the complete peeling (regression aga
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
> > > > Ok for trunk? Or should I delay this to GCC 6?
> > >
> > > Does this work even without the other patch?
> >
> > Yes, I've actually developed 2/2 first. The other patch only ever
On Mon, Jan 26, 2015 at 04:28:02PM +0100, Richard Biener wrote:
> Sure - but for unrolling
>
> int a[2];
> for (int i = 0; i < 5; i++)
> a[i] = i;
>
> I'd like to see warnings and we only warn if we unroll this because
> the value-range of i includes indexes that are valid.
Don't we warn her
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
> > > > Ok for trunk? Or should I delay this to GCC 6?
> > >
> > > Does this work even without the other patch?
> >
> > Yes, I've actually developed 2/2 first. The other patch only ever
On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
> > > Ok for trunk? Or should I delay this to GCC 6?
> >
> > Does this work even without the other patch?
>
> Yes, I've actually developed 2/2 first. The other patch only ever
> emits more warnings...
Then it probably should be ok
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
> On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote:
> >
> > This is the 2nd thing I came up with after looking at PR64277.
> > VRP does a poor job computing value-ranges of unrolled loop IVs
> > thus a very simple thing to do is to factor in
On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote:
>
> This is the 2nd thing I came up with after looking at PR64277.
> VRP does a poor job computing value-ranges of unrolled loop IVs
> thus a very simple thing to do is to factor in previous VRP results
> by intersecting what VRP2 com
This is the 2nd thing I came up with after looking at PR64277.
VRP does a poor job computing value-ranges of unrolled loop IVs
thus a very simple thing to do is to factor in previous VRP results
by intersecting what VRP2 computes with recorded SSA name range infos
(that also makes errors in those
