Re: gcc.dg/funcorder.c failure on pa64 - need advice

[law at redhat dot com]

In message <87ekqpzvu6.fsf@egil.codesourcery.com>, Zack Weinberg writes:
 >
 >gcc.dg/funcorder.c has been failing on pa64, because the functions 'q'
 >and 't' are not recognized as pure.  The code doing the recognizing is
 >mark_constant_function in alias.c, which gives up on any insn in the
 >function for which nonlocal_set_p or global_reg_mentioned_p is true.
 >For 'q', the insn that trips it up is
 >
 >(call_insn 28 27 29 1 (parallel [
 >            (set (reg:DI 28 %r28)
 >                (call (mem:SI (symbol_ref/v:DI ("@link_error") <function_decl
 > 800003ffff5a28f0 link_error>) [0 S4 A32])
 >                    (const_int 64 [0x40])))
 >            (clobber (reg:DI 1 %r1))
 >            (clobber (reg:DI 2 %r2))
 >            (clobber (reg:DI 4 %r4))
 >            (use (reg:DI 27 %r27))
 >            (use (reg/f:DI 29 %r29))
 >            (use (const_int 0 [0x0]))
 >        ]) -1 (nil)
 >    (nil)
 >    (nil))
 >
 >and the reason it's being tripped up is, CONST_OR_PURE_CALL_P is not
 >true for this insn, which causes both nonlocal_set_p and
 >global_reg_mentioned_p to return true.  't' falls afoul of a similar
 >call_insn.
 >
 >Looking at the source, the compiler indeed has no reason to believe
 >that it should treat the call to link_error as pure, and adding
 >
 >extern void link_error (void) __attribute__ ((pure));
 >
 >to the top of the file makes the test pass.  However, this raises the
 >question of why this test case passes on any target.  I am guessing
 >that on most targets this call is eliminated before we get to calling
 >mark_constant_function, but PA64 presents unusual difficulties for the
 >RTL optimizers, such that the call can't be optimized out until later.
 >I'd like second opinions on (a) whether this is the case, and (b)
 >whether adding the above declaration is the right thing to do, or if
 >not, what should be done instead.
 >
 >cc:ing Jeff and John as PA backend maintainers, Jan as author of the
 >test case.
Presumably the problem is the use of the DP register ($r27)?  It's been a
long long time since I looked at this stuff, but IIRC:

  1. %dp must have its correct value at each and every call site.  It's
     used in various ways inside the call sequences themselves.  It may
     even be used in the linker stubs.  This use needs to be exposed
     so that restores of the PIC register do not schedule after the
     call itself.  There may also be an ABI mandate that the PIC register
     be valid at a call site.

  2. For PA64 (which is what you appear to be compiling code for), %dp
     is also clobbered by each call (see PIC_OFFSET_TABLE_REGNUM and
     PIC_OFFSET_TABLE_REG_CALL_CLOBBERED).


jeff