on 2019/7/17 下午6:37, Richard Biener wrote: > On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin <li...@linux.ibm.com> wrote: >> >> Hi all, >> >> Based on the previous comments (thank you!), I tried to update the >> handling in expander and vectorizer. Middle-end optimizes lrotate >> with const rotation count to rrotate all the time, it makes vectorizer >> fail to vectorize if rrotate isn't supported on the target. We can at >> least teach it on const rotation count, the cost should be the same? >> At the same time, the expander already tries to use the opposite >> rotation optable for scalar, we can teach it to deal with vector as well. >> >> Is it on the right track and reasonable? > > So you're basically fixing this up in the expander. I think on > the GIMPLE level you then miss to update tree-vect-generic.c? >
Thanks, I will update it. Another question on variable rotation number, where is the best place I can add additional cost in vectorizer (for negate + possible maskgen/and)? Or to avoid this, transform the stmt to several stmts with opposite direction before vectorizer? > I'm not sure if it makes sense to have both LROTATE_EXPR and > RROTATE_EXPR on the GIMPLE level then (that CPUs only > support one direction is natural though). So maybe simply get > rid of one? One maybe impractical idea to have ROTATE_EXPR to unify and use positive or negative for the direction? > Its semantics are also nowhere documented > (do we allow negative rotation amounts? how are > non-mode-precision entities rotated? etc.). > I think negative rotation amount is ok, not sure non-mode-prec, it's a good point we should guard it when would like to use the opposite direction. Thanks, Kewen
