This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/70321] [6 Regression] STV generates less optimized code
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 22 Mar 2016 13:46:27 +0000
- Subject: [Bug target/70321] [6 Regression] STV generates less optimized code
- Auto-submitted: auto-generated
- References: <bug-70321-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Ilya Enkovich from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > For stage1, I wonder if it can't move earlier, say before the combiner. If
> > it could, then we could split the TARGET_STV patterns that weren't changed
> > into vector insns, and let the combiner deal with that. Is there a reason
> > why it is done after the combiner now?
>
> Yes, STV searches for ANDN pattern and also for DI comparison with zero
> executed via OR. Those are produced by combiner. I believe some STV tests
> would fail if we move it before combine.
Why couldn't STV just "vectorize" AND and NOT patterns and let the combiner
combine that in the vectorized code?