This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Machine Description '.md'
- To: ra990898 at ic dot unicamp dot br
- Subject: Re: Machine Description '.md'
- From: Nick Ing-Simmons <nik at tiuk dot ti dot com>
- Date: Tue, 13 Jun 2000 09:01:18 +0100 (BST)
- Cc: gcc at gcc dot gnu dot org, Mike Stump <mrs at windriver dot com>, Alan Lehotsky <lehotsky at tiac dot net>
- Organization: via, but not speaking for : Texas Instruments Ltd.
- References: <Pine.GSO.4.10.10006071759290.8268-100000@xingu.dcc.unicamp.br>
- Reply-To: Nick Ing-Simmons <nik at tiuk dot ti dot com>
Marcio De Oliveira Buss <ra990898@ic.unicamp.br> writes:
> 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. :-)
There is a "match operator" option too - so you can write one pattern
which can accept a "structure" rather than particular operations.
Your predicate functions need to check that what you are offered
is indeed possible with the current "architecture".
You need one such for each "shape" of insn you want to handle.
But then your backend code needs to be smart too and convert RTL
operator codes into assembly language rather than just doing a string
subsitute.
>
> -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
>>
--
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.