[LLVMdev] [LoopVectorizer] Missed vectorization opportunities caused by sext/zext operations

[Silviu Baranga]

Hi Sanjoy,

Yes, I was completely wrong about that, sorry.

I was probably thinking about the ule/sle cases and
the case where the increment can be something different
then 1. These can also be handled, but we would need
to test the range of whatever we're comparing against.

Thanks,
Silviu


> -----Original Message-----
> From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com]
> Sent: 06 May 2015 20:00
> To: Silviu Baranga
> Cc: Renato Golin; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] [LoopVectorizer] Missed vectorization opportunities
> caused by sext/zext operations
> 
> Hi Silviu,
> 
> >> void test0(unsigned short a, unsigned short *  in, unsigned short * out) {
> >>   for (unsigned short w = 1; w < a - 1; w++) //this will never overflow
> >>       out[w] = in[w+7] * 2;
> >> }
> >
> > Turns out this can actually overflow for a = 0, and in this case would
> > be an infinite loop (end condition would be w < MAX_USHORT). Run-time
> > checks could still be added here:
> 
> Maybe I'm missing something here, but for a = 0 this will run exactly
> (MAX_USHORT - 1) iterations, it will stop once w is MAX_USHORT.
> 
> In general, if your loop condition is "I u< N" for any N, I++ cannot unsigned
> overflow since the only value of I for which I++ overflows is MAX_USHORT (=
> -1) and MAX_USHORT will not be u< N for any N.  A similar fact follows for "I
> s< N" and sign overflow in I++.
> 
> >> I think it will be sufficient to add a couple of new cases to
> >> ScalarEvolution::HowManyLessThans --
> >>
> >>   zext(A) ult zext(B) == A ult B
> >>   sext(A) slt sext(B) == A slt B
> >
> > I had a go at this but realized that the problem above would affect at
> > least the ult case (we need to have B < max(type(B)) for it to hold),
> 
> Why?  AFAICT, the above two facts hold for all values of A and B, including
> INT_MAX, INT_MIN, INT_UMAX etc.
> 
> -- Sanjoy