search for: devector

Hi, Great to see someone working on this. This will benefit the performance portability goal of the pocl's OpenCL kernel compiler. It has been one of the low hanging fruits in improving its implicit WG vectorization applicability. The use case there is that sometimes it makes sense to devectorize the explicitly used vector datatype code of OpenCL kernels in order to make better opportunities for the "horizontal" vectorization across work-items inside the work-group. E.g., the last time I checked, the inner loop vectorizer (which pocl exploits) just refused to vectorize loops w...

...But I might have got that wrong. >> Also, llvmpipe uses intrinsics for some things, so it might be strange >> if we decompose IR operations but leave the intriniscs alone. > > The issue of intrinsics and vectorization was discussed some time ago. > There it might be better to devectorize to a scalar version of the > instrinsics (if available) as at least the loopvectorizer can vectorize > also a set of selected intrinsics, and the target might have direct > machine instructions for those (which could not be exploited easily from > "inlined" versions). Yeah...

Renato Golin <renato.golin at linaro.org> writes: > On 25 October 2013 11:06, Richard Sandiford <rsandifo at linux.vnet.ibm.com>wrote>> It would also need some TargetTransformInfo hooks to decide which >> vectors should be decomposed. > > If I got it right, this may not be necessary, or it may even be harmful. > > Say you decide that <4 x i32> vectors

On 25 October 2013 11:06, Richard Sandiford <rsandifo at linux.vnet.ibm.com>wrote: > I wanted the same thing for SystemZ, which doesn't have vectors, > in order to improve the llvmpipe code. > Hi Richard, This is a nice patch. I was wondering how hard it'd be to do that, and it seems that you're catching lots of corner cases. My interest is also due to converting odd