Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle <roger@eyesopen.com>]

The following reply was made to PR target/8087; it has been noted by GNATS.

From: Roger Sayle <roger@eyesopen.com>
To: "David S. Miller" <davem@redhat.com>
Cc: <davem@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
        <ghazi@caip.rutgers.edu>, <rth@redhat.com>, <jakub@redhat.com>,
        <gcc-gnats@gcc.gnu.org>
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in
 execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Mon, 7 Oct 2002 12:04:10 -0600 (MDT)

 >    The fixes that I'm still investigating address the sparc64 backend's
 >    convoluted constant pool loading code.
 >
 > There is nothing convoluted about it.  That's a perfectly valid
 > and fine way to output a load from the constant pool and expose
 > all of the instructions to the compiler for scheduling purposes.
 
 I beg to differ.
 
 The sparc64 backend represents a load from the constant pool as:
 
 (mem/u/f:DF (lo_sum:DI (reg/f:DI 110)
                        (symbol_ref/u:DI ("*.LLC0"))) [2 S8 A64]
 
 The problem is that the code in "avoid_constant_pool_reference"
 in simplify-rtx.c (line 149), assumes that constant pool references
 are of the form "(mem (symbol_ref ...))".  Indeed the macro
 CONSTANT_POOL_ADDRESS_P assumes that it is always passed a naked
 symbol_ref.
 
 A possible fix may be to extend this test is also allow the constant
 pool to be indexed via LO_SUM.  Something like:
 
 	if (GET_CODE (x) != MEM)
 	  return x;
 	addr = XEXP (x, 0)
 
 +	if (GET_CODE (addr) == LO_SUM
 +	    && GET_CODE (XEXP (addr, 1)) == SYMBOL_REF)
 +	  addr = XEXP (addr, 1);
 
 	if (GET_CODE (addr) != SYMBOL_REF
 	    || ! CONSTANT_POOL_ADDRESS_P (addr))
 	  return x;
 
 
 Could someone that understands LO_SUM targets confirm that this is
 a reasonable thing to do?  I'm assuming that the ".LLC0" symbol_ref
 will be correctly marked with CONSTANT_POOL_ADDRESS_P.  If it is,
 this should not only solve 20020720-1.c, but also enable many more
 optimizations on sparc64.  RTH?
 
 Roger
 --