This is the mail archive of the
mailing list for the GCC project.
Re: Question about constraints and reload
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: stevenb at suse dot de (Steven Bosscher)
- Cc: weigand at i1 dot informatik dot uni-erlangen dot de (Ulrich Weigand), gcc at gcc dot gnu dot org
- Date: Sat, 25 Sep 2004 18:39:07 +0200 (CEST)
- Subject: Re: Question about constraints and reload
Steven Bosscher wrote:
> 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.
Eh? Reload introduces new register uses all the time, for many different
purposes (e.g. address reloads). The force-const-to-mem is actually one
of the few operations reload does that typically does *not* need a new
> So I thought perhaps we should be more strict about satisfying operand
> constraints before reload. Hence my question.
This is kind of contradictory -- the primary purpose of the reload pass
is to satisfy operand constraints. If they were always satisfied before
reload we wouldn't need it ...
> 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.
The problem is that there isn't a single set of non-legitimate constants
vs. legitimate constants. What's legitimate depends very much on the
particular assembler instruction -- in some cases it's impossible to
tell on the tree level which constants are legitimate; even on the *rtl*
level it may not be possible to decide before reload has actually
chosen an insn alternative.
Dr. Ulrich Weigand