This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc intrinsics for am33 parallel integer arithmetic
- To: Matthew Hiller <hiller at cygnus dot com>
- Subject: Re: gcc intrinsics for am33 parallel integer arithmetic
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 29 Aug 2000 15:29:43 -0600
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <Pine.LNX.4.21.0008281623250.13848-100000@breve.cygnus.com>you wri
te:
> The am33 has a set of parallel integer arithmetic instructions
> that execute two integer arithmetic operations simultaneously. This patch
> implements 36 of them as intrinsics. Binutils already supports these
> instructions. (Testcases that use these intrinsics will follow in a
> separate patch.)
>
> 2000-08-28 Matthew Hiller <hiller@cygnus.com>
>
> * config/mn10300/dsp.h: New file.
> (__ADD_ADD, __ADD_SUB, etc): Prototypes for intrinsics.
You need a copyright notice for the new file. Also note that most of the
time we haven't bothered providing prototypes for target specific intrinsics
(though one can certainly argue that we should).
> + (define_insn "add_add"
> + [(set (match_operand:SI 1 "nonimmediate_operand" "+&dax")
> + (plus:SI (match_dup 1)
> + (match_operand:SI 0 "general_operand" "idax")))
> + (set (match_operand:SI 3 "nonimmediate_operand" "+&dax")
> + (plus:SI (match_dup 3)
> + (match_operand:SI 2 "general_operand" "idax")))]
> + "TARGET_AM33"
> + "add_add %0,%1,%2,%3"
> + )
I like having these as PARALLELs -- while we can't really have the compiler
generate them on its own now, we can describe precisely what they do in RTL
so that if the user uses a builtin to get these insns the compiler will know
their semantics.
However, a couple tidbits on the pattern.
First, for a matching inout operand we usually use a constraint to ensure
that the input and output operands are the same register (instead of a
match_dup). That gives the compiler more freedom when generating and
optimizing these instructions.
Doing that would eliminate the need for the "+" in the output constraints.
Second, the "&" means that the output operand is written before all the inputs
have been read. I don't believe that's what we really want here. It's been
a while since I looked at the am33 dsp extensions, but my recollection was
that the only case that was undefined as having both outputs in the same
register (which shouldn't ever happen -- if it did, then something else is
terribly wrong in the compiler). Thus, I don't think the "&" is necessary.
How do those insns effect the status of the condition code register? You may
want to refine the patterns to properly track cc0 status.
jeff