This is the mail archive of the gcc-bugs@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]

[Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]