This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi all, This patch follows the idea to improve rs6000 backend instead of generic expander. I think this is a better solution? I was thinking generic expander change may benefit other targets suffering similar issues but the previous RFC seems too restricted on const rotation count, although it's possible to extend. Any comments on their pros/ cons are really helpful to me (a noob). Regression testing just launched, is it OK for trunk if it's bootstrapped and regresstested on powerpc64le-unknown-linux-gnu? Thanks, Kewen ---- gcc/ChangeLog 2019-07-17 Kewen Lin <linkw@gcc.gnu.org> * config/rs6000/predicates.md (vint_reg_or_const_vector): New predicate. * config/rs6000/vector.md (vrotr<mode>3): New define_expand. gcc/testsuite/ChangeLog 2019-07-17 Kewen Lin <linkw@gcc.gnu.org> * gcc.target/powerpc/vec_rotate-1.c: New test. * gcc.target/powerpc/vec_rotate-2.c: New test. on 2019/7/16 下午4:45, Kewen.Lin 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? > > > Thanks, > Kewen >
Attachment:
expand_v1.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |