This is the mail archive of the
mailing list for the GCC project.
Re: Question about constraints and reload
- From: <tm_gccmail at kloo dot net>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>,gcc at gcc dot gnu dot org
- Date: Mon, 27 Sep 2004 04:50:38 -0700 (PDT)
- Subject: Re: Question about constraints and reload
On Sat, 25 Sep 2004, Steven Bosscher wrote:
> 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?
> (bits removed for brevity)
> 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.
This fits nicely into the midRTL/targetRTL paradigm.
The register allocator will still need to generate literal pool entries
for accessing deep stacks on machines with limited displacements on
indirect addressing modes, however.