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>, rth at cygnus dot com
- Subject: Re: How to clean up i386 machine description?
- From: Richard Henderson <rth at cygnus dot com>
- Date: Fri, 6 Nov 1998 17:54:12 -0800
- Cc: law at cygnus dot com, pcg at goof dot com, egcs at cygnus dot com
- References: <19981106141440.A26877@dot.cygnus.com> <199811070053.QAA16182@Sunburn.Stanford.EDU>
- Reply-To: Richard Henderson <rth at cygnus dot com>
On Fri, Nov 06, 1998 at 04:53:42PM -0800, Colin Douglas Howell wrote:
> Why does the x86 require a unique solution to this problem? Granted,
> it's a complex architecture with many different implementations, each
> of which has different scheduling properties. But this isn't
> fundamentally different from most RISC architectures out there today;
The fundamental difference is that on most RISC machines, each opcode
has only one set of scheduling characteristics. All inputs are either
registers or small constants, and all registers are considered equal.
The x86, on the other hand, it makes a good deal of difference whether
an input to "add" is a memory operand, the number 1, an immediate other
than 1, eax, a register other than eax, etc. All of these things affect
which instruction variant will be selected, and how that variant should
be scheduled.
If all these variants were broken out into different instruction patterns,
at least initially, we very negatively affect the options open to reload.
And even defining post-reload splitters may be intractable because of the
number of extra patterns that would be required.
So my thought was to define instruction attributes that select the
instruction variant and determine the scheduling class, and use this
information directly by the scheduler, and by the insn output routines.
In this way we have no duplicated code (for the scheduler and for the
output routines) to get out of sync.
r~