This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
register.

> 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.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]