Re: [testcase] ia64 retaddr elimination failure

[Jim Wilson <wilson at cygnus dot com>]

This testcase is very IA-64 specific.  It works because reload is setting
frame_pointer_needed wrong.  builtin_frame_address emits a direct reference
to HARD_FRAME_POINTER_REGNUM, which in the IA-64 port is the last allocatable
register.  But since there is no frame pointer according to reload, the IA-64
prologue code is confused into thinking that all allocatable regs have been
used.  Thus the return_address gets saved on the stack instead of in a
register, causing builtin_return_address to fail.  This is very unlikely to
ever fail the same way on any other target.

The testcase is OK if you put it in gcc.dg instead, with a dg-compile line
mentioning ia64-*-*.

The reload problem is that it checks all uses of FRAME_POINTER_REGNUM to see
if they are eliminable.  If they are, then we don't need a frame pointer.
However, on targets where HARD_FRAME_POINTER_REGNUM != FRAME_POINTER_REGNUM,
we still need a frame pointer if there are any direct uses of the hard
frame pointer.  This check is missing.  We either need to add this check to
reload, or else change builtins.c to use frame_pointer_rtx instead of
hard_frame_pointer_rtx.  Either way, this isn't a change I feel comfortable
making for an obscure bug when we are this close to a release.

With this reload problem fixed, you would need a much larger testcase to
reproduce the builtin_return_address problem, as then you would need to
actually use all allocatable registers before it failed.

To make builtin_return_address work in all cases, we need to make it a MEM
by default, and then force the return address to the stack.  The current
RETURN_ADDR_RTX macro is trying to emit efficient code by default, but this
fails when we run out of registers.  If we emit inefficient code by default,
then we can make it work in all cases.

This leaves us with a hard choice.  We can either get efficient code for
a compiler builtin that works for all internal gcc uses, or we can get
inefficient code that also works for end users.  Personally, I'd rather have
the efficient code.  I think it is a serious design flaw that gcc internal
builtin functions are even available to end users.  So for now, I think it
is OK to leave this broken, but we should add your testcase to remind us that
it is broken.

Jim