Re: How to clean up i386 machine description?

[Colin Douglas Howell <howell at cs dot stanford dot edu>]

Joern Rennecke writes:
> 
> > > There [might] be a sequence that sets a register to one and then
> > > adds/subtracts that value from another register.  Reload might
> > > know about the equivalence and decide to replace the register
> > > with the constant one in the add / subtract.  The instruction
> > > number is not recalculated in reload.
> > Maybe stupid question, but why it should not be changed and recog the
> > insn again?
> 
> During reload, one or more operands can be ill-formed.  Only when reload
> is finished can we be confident that the operands are all fixed up.
> Hence, if we'd try to re-recognize an instruction during reload, this
> would likely fail.

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.

The sets used before and after reload are designed to precisely select
an instruction for scheduling and/or output.  They would use operand
predicates to accomplish this.  This would require multiple patterns
for the different possible combinations of allowed operands, since you
can only use a single predicate per operand in a define_insn.  The
pre-reload set could also use the tightest possible operand predicates
in order to minimize the work to be done by reload later.

The set used during reload, on the other hand, would serve to tell
reload what combinations of operands were legal, so it could fix them
up properly.  This would require a complete description of all the
possible operand types in the constraints, as well as very general
operand predicates which matched the union of the constraints.
Several different types of instructions might be handled in a single
pattern, which would in effect let reload select from a variety of
instruction types to satisfy its goals.

Granted, this solution might greatly increase the number of patterns.
It's also just a kluge to get around the limitations of reload and
instruction pattern definitions.  In many cases a simpler
constraint-driven multiple alternative approach might still be the
best one.  But I think the idea of using several sets of patterns
might be worth considering, at least for some patterns.

-- 
Colin Douglas Howell                    Systems Administrator
e-mail:  howell@cs.stanford.edu         Computer Facilities Group
office:  (650) 723-2491                 Computer Science Department
                                        Stanford University