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

Re: gcc intrinsics for am33 parallel integer arithmetic



  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



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