Re: Machine Description '.md'

[Marcio de Oliveira Buss <ra990898 at ic dot unicamp dot br>]

	I think every RTL insn emitted by a DEFINE_EXPAND must match some
 DEFINE_INSN in the machine description. But in my sort of application,
 I would like to modify the machine description in order to adequate it
 to a reconfigurable architecture. But I would not like to have fixed
 patterns, even this patterns being various conditional patterns under
 some conditional rules. I would like to add some patterns that I have
 never been though before. I would like to discover this patterns from 
 the source program, for instance, some sequences of instructions that
 appear many times in the code. I think that the 'combine' fase of
 the compiler do this task, but always based in the fixed machine
 description.
	Therefore, I have a problem.  :-)

	-Marcio.

*************************************
 "Civilization advances by extending
  the number of important operations
  which we can perform without
  thinking about them."
        Alfred North Whitehead, 1911
*************************************


On Wed, 7 Jun 2000, Alan Lehotsky wrote:

> At 12:31 PM -0700 6/7/00, Mike Stump wrote:
> >..
> 
> ..
> 
> >Yes or no, depending upon the design.  There are companies now that
> >have reconfigurable CPU architectures, that use gcc for
> >compilations.  One way to do it, would be to just add predicates to
> >instructions (for example the entire floating point unit):
> >
> >/* Nonzero if we should generate code to use the fpu.  */
> >#define MASK_FPU 1
> >#define TARGET_FPU (target_flags & MASK_FPU)
> >
> >(define_expand "cmpsf"
> >   ;; The 96 here isn't ever used by anyone.
> >   [(set (reg:CCFP 96)
> >   (compare:CCFP (match_operand:SF 0 "register_operand" "")
> >		      (match_operand:SF 1 "register_operand" "")))]
> >   "TARGET_FPU"
> >   "
> 
> 	Good concept, but in general a predefined NAMED pattern has
> 	to have a compile-time constant predicate, because they
> 	tend to appear in
> 
> 
> 	#if HAVE_XXXXXX
> 	...
> 	#endif
> 
> 	preprocessor blocks.  I'm guessing that you've extracted code
> 	from a real .md file, so clearly the FP instructions aren't
> 	subject to this limitation....
> 
> 	You can of course have the DEFINE_EXPAND's code body
> 	make runtime decisions about what sort of RTL to generate,
> 	and you can always have unnamed DEFINE_INSN patterns that
> 	are conditional on executable test expressions.
> 
> 	RELATED THOUGHT:  It seems to me that there is NO circumstance
> 			where an anonymous DEFINE_EXPAND can be
> 			useful.  Right?
> 
> -- Al
> 
> -- 
> ------------------------------------------------------------------------
> 
> 		    Quality Software Management
> 		http://www.tiac.net/users/qsmgmt
> 			apl@alum.mit.edu
> 			(978)287-0435 Voice
> 			(978)808-6836 Cell
> 			(978)287-0436 Fax
> 
> 	Software Process Improvement and Management Consulting
> 	     Language Design and Compiler Implementation
>