This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: target/7856: [arm] invalid offset in constant pool reference
- From: Philip Blundell <pb at nexus dot co dot uk>
- To: rearnsha at gcc dot gnu dot org
- Cc: gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nickc at redhat dot com, nobody at gcc dot gnu dot org, rearnsha at arm dot com
- Date: 09 Sep 2002 12:22:38 +0100
- Subject: Re: target/7856: [arm] invalid offset in constant pool reference
- References: <20020909105644.20398.qmail@sources.redhat.com>
On Mon, 2002-09-09 at 11:56, rearnsha@gcc.gnu.org wrote:
> However, I'm not yet convinced that Nick's change is for the
> best overall.
Well, mmm, it's tricky to know which gives you better code on average.
XScale makes it worse, because the penalty for using ldm/stm is greater
on those devices - you pay something like a two-cycle startup cost, plus
one cycle for every register transferred. So pushing LR unnecessarily
could cost you three cycles at entry and the same at exit, if you only
had one other register to save.
Presumably we could avoid the particular problem at hand by making
use_return_insn() detect this situation - it already does this for
interworking, which is the other main case where
output_return_instruction would generate a 2-instruction sequence.
p.