[PATCH] Add a Scalarize pass

Renato Golin renato.golin at linaro.org
Sat Nov 9 21:47:08 PST 2013


  I can see use for this pass in two cases:
   1. when the original code uses vectors that the target does not support, example when compiling OpenCL into CPU code, or SIMD intrinsics into scalar CPU code
   2. when some optimization breaks the IR for your specific target/language/options combinations, but you still need some of the benefits of those passes

  Number 2 should be fixed elsewhere, but number 1 is a valid, and very important case.

  In the OpenCL case, the front-end should add this pass, since it's already changing the passes anyway. I'd guess that after complete scalarization, the vectorizers should take care of putting up SIMD code back in shape by re-building CPU-valid vectors.

  In the SIMD to scalar case, it might not be that trivial. With this pass, it should be possible to compile SIMD intrinsics, even though the specific CPU doesn't support them, supposing all intrinsics will be converted to vector code, not intrinsic calls. In this case, inspecting the target info would be the place to take the decision, BUT, there are other things to take into account first, for instance, if we hit an intrinsic that cannot be expanded, it'll be an assert, rather than a user error, a problem that will have to be fixed first.

  If you're interested in other cases where the TTI is the right place to add this info, other than the one above, please let us know.

  --renato

http://llvm-reviews.chandlerc.com/D2112



More information about the llvm-commits mailing list