This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile 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: Sat, 15 Jun 2013 17:10:57 +0000
- Subject: [Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)
- Auto-submitted: auto-generated
- References: <bug-57623-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to sgunderson from comment #2)
> On Sat, Jun 15, 2013 at 04:33:14PM +0000, jakub at gcc dot gnu.org wrote:
> > The fix for the compiler is easy, but at least the AVX2 spec documents that
> > _bextr_u{32,64} intrinsics actually take 3 arguments (source, start and
> > length),
> > with the latter two always unsigned int, while our intrinsic has only two
> > arguments (where the latter is expected to be (start & 255) | (length << 8)).
> > Not sure if we want to change this, and if so, just for 4.9+, or also for
> > 4.8.2+ and 4.7.4+?
>
> If you decide to change it, at least consider keeping the old version around;
> for instance, the start/length combination could come from a table. In
> general, if you actually have to do shifting and stuff to create this
> operand, the gain of the instruction is already lost.
If both start and length are constants, then it will be folded by the compiler,
similarly if you use it inside of loop and start/length will be loop
invariants, the computation can be hoisted out of the loop.
While C++ has function overloading, C does not, so we can't have both with the
same name.