Question about constraints and reload

[Steven Bosscher]

On Saturday 25 September 2004 16:56, Ulrich Weigand wrote:
> Steven Bosscher wrote:
> >What is this necessary for, is there any reason to rely on reload to
> >turn a constant into a MEM?
>
> Certainly!  Reload will, as one of its options, force a constant to
> the literal pool, thereby turning the operand into a MEM.  The s390
> port relies extensively on that feature, because we can only use a
> limited set of immediate operands, and these differ widely between
> different instructions.  Thus the best way to handle constants is
> to allow them more or less freely before reload, and have reload
> choose to use either an actual immediate operand where available,
> reload the constant into a register, or else push it into the
> literal pool.

Maybe it's the *easiest* way for your port and other ports to handle
constants this way, but it may not be the "best way" ;-)  I suppose
you would want to keep constants around mostly for optimization, but
do we still need that, if the tree optimizers do most of the work?

These loose constraints looks like the kind of thing that make it so
hard to write a decent register allocator.
In some discussions about that recently on IRC (I plan to turn the log
of that into a Wiki page), one of the things the new-ra people mentioned,
was that the constraints on register classes and strict constraints on
insn operands were notsatisfied during register allocation.  This would
cause reload to sort of redo the whole register allocation even after
new-ra was done.

With reload turning a constant into a MEM and (probably) a load to a
register, I would guess you introduce new register uses in reload, and
suddenly it's not that surprising that reload has to redo new-ra's work.

So I thought perhaps we should be more strict about satisfying operand
constraints before reload.  Hence my question.

Perhaps we can experiment with putting non-legitimate constants into the
constant pool and turn them into MEMs somewhere *before* greg and reload.
Perhaps even already somewhere late in the tree optimizers (turn them 
into CONST_DECLs), or otherwise in some pre-regalloc pass.

Gr.
Steven