This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix up bmi_bextr_<mode> (PR target/57623)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Date: Tue, 18 Jun 2013 11:51:41 +0200
- Subject: Re: [PATCH] Fix up bmi_bextr_<mode> (PR target/57623)
- References: <20130617161152 dot GZ2336 at tucnak dot redhat dot com> <CAFULd4amtuuZzoLVB0xvE4vstmPuGNHgH+0rdY=4enB0OLheQQ at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jun 18, 2013 at 11:47:29AM +0200, Uros Bizjak wrote:
> On Mon, Jun 17, 2013 at 6:11 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>
> > This instruction has the predicates/constraints wrong, the r/m argument is
> > the middle-one, the value from which it should be extracted, rather than
> > the packed start/length argument. This got broken with PR50766, where the
> > patch hasn't touched just BMI2, but for unknown reasons also this BMI
> > instruction which was handled right in GCC 4.6.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8/4.7?
> >
> > BTW, the AVX2 docs document _bextr_u{32,64} 3 argument intrinsics, rather
> > than the __bextr_u{32,64} 2 argument intrinsics we have in GCC right now.
> > Something to fix up (as the names are different, perhaps we can both the old
> > ones and the new ones implemented say as return __bextr_u32 (x, (y & 255) |
> > (z << 8)); or similar)?
>
> It looks to me that GCC's double-underscored version is wrong. We are
> looking for compatibility with official bmiintrin.h header. Kirill,
> can you please comment on this issue?
Well, bmiintrin.h has been added first as an AMD ISA extension, and I think for
AMD extensions the GCC headers are the official place (the AMD docs don't
mention the intrinsics at all), and only later on also added as Intel ISA
extension. So I'd say it is fine to keep the __bextr_* variants (as written
in the PR, sometimes the two argument ones can be useful if you e.g.
precompute the start/length pairs ahead of time) and just add the one
underscored ones to match ICC/AVX2 documentation.
Jakub