search for: costtabl

...Or if the runtime condition in which it could be vectorize is not valid, in which case you have to run the original. Second, on x86 and possibly other targets, the encoding of vector > instructions takes more space. > This may be a problem, and maybe the solution is to build a "SizeCostTable" and do the same as we did for the CostTable. Most of the targets would just return 1, but some should override and guess. However, on ARM, NEON and VFP are 32-bits (either word or two half-words), but Thumb can be 16-bit or 32-bit. So, you don't have to just model how big the vector ins...

Hi Hal, On Feb 4, 2013, at 2:09 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Arnold Schwaighofer" <aschwaighofer at apple.com> >> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com>, "Hal

Hi, I would like to start a discussion about enabling the loop vectorizer by default for -Os. The loop vectorizer can accelerate many workloads and enabling it for -Os and -O2 has obvious performance benefits. At the same time the loop vectorizer can increase the code size because of two reasons. First, to vectorize some loops we have to keep the original loop around in order to handle the last