This is the mail archive of the
mailing list for the GCC project.
Re: [patch 2/2] AMD bdver2 processors - TBM
- From: Quentin Neill <quentin dot neill dot gnu at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 4 Nov 2010 11:43:46 -0500
- Subject: Re: [patch 2/2] AMD bdver2 processors - TBM
- References: <AANLkTimu68wDKTwxP2bfvHdr+VK_rndkQuHjX4xHL1vJ@mail.gmail.com> <AANLkTi=MZRqhi1=jQ03C8-=djK4tdW=sQJ5FgKExj06Y@mail.gmail.com> <4CCCBE41.firstname.lastname@example.org> <AANLkTinmzgspzmeeYQf8M9QHMNpbkBnPqKZ2ENi4x3eg@mail.gmail.com> <4CD2DD2D.email@example.com>
On Thu, Nov 4, 2010 at 11:19 AM, Richard Henderson <firstname.lastname@example.org> wrote:
>> + ?[(set_attr "type" "bitmanip")
>> + ? (set_attr "mode" "<MODE>")])
> Watch the extra vertical whitespace.
So should I have two lines (to separate list of ';TBM instructions')
or just one?
>> +extern __inline unsigned int __attribute__((__gnu_inline__, __always_inline__, __artificial__))
>> +__bextri_u32 (unsigned int __X, const unsigned int __I)
>> + ? ? unsigned char length ? ?= ((__I >> 8) & 0xFF);
>> + ? ? unsigned char lsb_index = (__I & 0xFF);
>> + ? ? return __builtin_ia32_bextri_u32 (__X, length, lsb_index);
> If you hadn't created the bextri builtin with three arguments,
> you wouldn't have to play the tricks you're doing here to make
> sure that the final arguments are constants.
> Unless you want to expose both constants to the user intrinsic
> (which isn't a horrible idea if you are not already constrained
> by external documentation of these), there's no reason you can't
> pull apart the two bytes of the immediate inside the builtin
> expander instead.
I was a little uneasy with this little wart as well. I was following
your feedback "the builtin function would need a bit of tweaking".
The builtin signature follows the signature of the BEXTR insn (and an
internal standard set for other compilers).
So pulling the two bytes out in the builtin expander - should that be
done with a *new* define_expand? Or is there a set of RTX operations
(shift, mask) I should use in the define_insn as written?
Any hints appreciated :)
And good catch on all the others, thanks.