search for: epilogvf

...egrade the performance, with my limited tests I have observed 16 is a point it shows gains with one of our internal benchmark. This require more experiments & testing to decide what should be the minimum width. 5) Unrolling issues: As Ayal mentioned with large unroll factor the next profitable EpilogVF could be equal to VF. With the same reason the current patch enforces UF=1, as unrolling can minimize the possibility of executing epilog vector loop. Example to understand the new layout: void foo (char *A, char *B, char *C, int len) { int i = 0; for (i=0 ; i< len; i++) A[i] = B[i] +...

On 02/22/2017 11:52 AM, Adam Nemet via llvm-dev wrote: > Hi Ashutosh, > >> On Feb 22, 2017, at 1:57 AM, Nema, Ashutosh via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> This is a proposal about epilog loop vectorization. >> Currently Loop Vectorizer inserts an epilogue loop for handling loops

...my limited tests I have observed 16 is a point it shows gains with one of our internal benchmark. This require more experiments & testing to decide what should be the minimum width. >> >> 5) Unrolling issues: >> As Ayal mentioned with large unroll factor the next profitable EpilogVF could be equal to VF. >> With the same reason the current patch enforces UF=1, as unrolling can minimize the possibility of executing epilog vector loop. >> >> Example to understand the new layout: >> >> void foo (char *A, char *B, char *C, int len) { >> in...

...the first place (although it would imply some gymnastics when examining the control flow around the loop and then restructuring things when we generate the code for the loop). The scalar remainder loop, when reached from the vectorized loop, is already known to be vectorizable to a VF larger than EpilogVF. No need to introduce again any potential aliasing, wrapping or whatnot checks, even if this redundancy can later be eliminated, if instead this vectorizability property could be recorded somehow. Similar to having annotated the remainder loop with “#pragma clang loop vectorize(assume_safety)”, exc...

There's another issue with re-running the vectorizer (which I support, btw - I'm just saying there are more problems to solve on the way :-) ) Historically, we haven't even tried to evaluate the cost of the "constant" (not per-iteration) vectorization overhead - things like alias checks. Instead, we have hard bounds - we won't perform alias checks that are "too