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 07:58:22 -0700 (PDT)
- Subject: Re: Question about constraints and reload
On Sat, 25 Sep 2004, Steven Bosscher wrote:
> 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.
Steven just prodded me into posting a more verbose reply, so here are my
recent thoughts on this subject - my apologies if I ramble somewhat, since
it's so early in the morning.
Some other functionality of reload which seem obvious to move
into a separate pass (besides literal pool generation) are:
o 3AC to 2AC conversion
o reload_cse (which IMHO should be handled in the regalloc - see below)
Regarding register allocation:
When we do a new register allocator:
We really need to defer assignment of stack locations for automatics until
the register allocation pass. This would be nice for multiple reasons,
such as more efficient code generation on short displacement targets and
the ability to pack HImode/QImode stack slots, ability to merge stack
slots with non-overlapping lifetimes, etc.
We really needs a target-dependent hook to allow reordering of the stack
slots before any code is generated. We did this as a Renesas project, and
saw a significant performance improvement on the SH; it should also help
MIPS16/Thumb signification, and even Alpha/PPC/MIPS targets if somebody
allocates a 32k array at the bottom of the stack.
We really need to make it easily extensible to handle different methods of
reducing register pressure, like live-range splitting, complex
rematerialization (like Mukta did), etc. We encountered a lot of problems
modifying new-ra to handle complex remat; it would be nice if the next ra
was more easily extensible.