| Message ID | CAFULd4akDsZJ6OUZb2a6rOMtGFL362FrOq1uVhPJ14osmbKu2A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Jan 20, 2014 at 09:49:16PM +0100, Uros Bizjak wrote: > Hello! > > Just unhandled V16SFmode in one of the new avx512 patterns. > > 2014-01-20 Uros Bizjak <ubizjak@gmail.com> > > PR target/59685 > * config/i386/sse.md (*andnot<mode>3<mask_name>): Handle MODE_V16SF > mode attribute in insn output. > > Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN. Shouldn't the testcase be added too? > Index: sse.md > =================================================================== > --- sse.md (revision 206844) > +++ sse.md (working copy) > @@ -8906,6 +8906,8 @@ > tmp = "pandn"; > break; > > + case MODE_V16SF: > + gcc_assert (TARGET_AVX512F); > case MODE_V8SF: > gcc_assert (TARGET_AVX); > case MODE_V4SF: Jakub
On Mon, Jan 20, 2014 at 10:14 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> Just unhandled V16SFmode in one of the new avx512 patterns. >> >> 2014-01-20 Uros Bizjak <ubizjak@gmail.com> >> >> PR target/59685 >> * config/i386/sse.md (*andnot<mode>3<mask_name>): Handle MODE_V16SF >> mode attribute in insn output. >> >> Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN. > > Shouldn't the testcase be added too? The solution is trivial in such way that it has no chance to regress. Uros.
On Mon, Jan 20, 2014 at 10:17:35PM +0100, Uros Bizjak wrote: > On Mon, Jan 20, 2014 at 10:14 PM, Jakub Jelinek <jakub@redhat.com> wrote: > > >> Just unhandled V16SFmode in one of the new avx512 patterns. > >> > >> 2014-01-20 Uros Bizjak <ubizjak@gmail.com> > >> > >> PR target/59685 > >> * config/i386/sse.md (*andnot<mode>3<mask_name>): Handle MODE_V16SF > >> mode attribute in insn output. > >> > >> Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN. > > > > Shouldn't the testcase be added too? > > The solution is trivial in such way that it has no chance to regress. I e.g. wonder why the insn is there also for V[248]DFmode, when it would ICE for those modes for -mavx2 or later (unless single packed modes are optimal). Jakub
On Mon, Jan 20, 2014 at 10:37 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> >> Just unhandled V16SFmode in one of the new avx512 patterns. >> >> >> >> 2014-01-20 Uros Bizjak <ubizjak@gmail.com> >> >> >> >> PR target/59685 >> >> * config/i386/sse.md (*andnot<mode>3<mask_name>): Handle MODE_V16SF >> >> mode attribute in insn output. >> >> >> >> Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN. >> > >> > Shouldn't the testcase be added too? >> >> The solution is trivial in such way that it has no chance to regress. > > I e.g. wonder why the insn is there also for V[248]DFmode, when it would > ICE for those modes for -mavx2 or later (unless single packed modes are > optimal). VI mode iterator does not include vector float modes. Uros.
Index: sse.md =================================================================== --- sse.md (revision 206844) +++ sse.md (working copy) @@ -8906,6 +8906,8 @@ tmp = "pandn"; break; + case MODE_V16SF: + gcc_assert (TARGET_AVX512F); case MODE_V8SF: gcc_assert (TARGET_AVX); case MODE_V4SF:
Hello! Just unhandled V16SFmode in one of the new avx512 patterns. 2014-01-20 Uros Bizjak <ubizjak@gmail.com> PR target/59685 * config/i386/sse.md (*andnot<mode>3<mask_name>): Handle MODE_V16SF mode attribute in insn output. Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN. Uros.