This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to clean up i386 machine description?
- To: Colin Douglas Howell <howell at cs dot stanford dot edu>
- Subject: Re: How to clean up i386 machine description?
- From: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Date: Mon, 16 Nov 1998 17:28:31 +1300 (NZDT)
- Cc: amylaar at cygnus dot co dot uk (Joern Rennecke), hubicka at horac dot ta dot jcu dot cz, rth at cygnus dot com, law at cygnus dot com, pcg at goof dot com, egcs at cygnus dot com
- References: <199811140644.GAA06668@phal.cygnus.co.uk><199811152001.MAA10403@Sunburn.Stanford.EDU>
Colin Douglas Howell writes:
> This gives me a interesting thought. We have several requirements
> here. One is to write the instruction patterns so that we know what
> type of instruction has been selected for scheduling and output
> purposes. A second is to tighten the operand predicates so we
> minimize the amount of work done by reload. Finally, we must write
> the patterns so that reload can do a good job of fixing up operands at
> minimal cost. Since in many cases the type of instruction we will
> select depends greatly on the operands, and since reload is modifying
> the operands, these requirements may be in conflict.
>
> Suppose we solve them by replacing each pattern with three sets of
> patterns, one to be used before reload, one during reload, and one
> after.
Hmmm, this looks like a pattern explosion! I haven't been following
this thread too closely so I might have the wrong end of the stick.
I gather you're wanting to tighten up the operand predicates for the
x86 and are having trouble with the weird combination of valid
operands.
If this is the case, what I suggest you do is to use the extra
condition field of the patterns to reject invalid combinations of the
operands. I did this with the C4x target where I wanted to minimise
the amount of reloading. On the x86 you'll probably find that the
predicates match almost anything but that there are limited
combinations of valid operands.
Michael.