Re: solaris build problem with Sun compilers

[Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>]

Tom Lane wrote:
> Alan Stange <stange(at)rentec(dot)com> writes:
> > I believe the trick here is that Solaris 10 will only run on v9 hardware 
> > (or the sun4u systems), which all have the instruction.   But the v8 ABI 
> > "model" doesn't have it.   So, in some sense the ABI doesn't "allow" 
> > this instruction, but the hardware does, so they can just slam it in 
> > knowing that it'll work.
> 
> Well, that might be OK for Sun's compiler since they know what a given
> version of Solaris will run on.  But I don't think we can adopt the same
> attitude for our gcc code path; that has to work on Sparc-based Linuxen
> and BSDen.  I don't think it's appropriate to kiss off support for v8
> chips when we haven't seen any proof at all of a performance boost in
> return.
> 
> Maybe the right answer is to leave the code as-is, ie, deliberately not
> the same for Sun and gcc compilers.

OK, I have applied the following patch which documents that the Solaris
CC TAS ASM only works for sparc9.  Hopefully either sparc8 is not needed
(unlikely) or someone will fix it.  I have CC'ed the original
contributor who added "cas".

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Index: src/backend/port/tas/solaris_sparc.s
===================================================================
RCS file: /cvsroot/pgsql/src/backend/port/tas/solaris_sparc.s,v
retrieving revision 1.6
diff -c -c -r1.6 solaris_sparc.s
*** src/backend/port/tas/solaris_sparc.s	17 May 2006 22:06:19 -0000	1.6
--- src/backend/port/tas/solaris_sparc.s	17 May 2006 23:42:40 -0000
***************
*** 16,21 ****
--- 16,38 ----
  	.global pg_atomic_cas
  pg_atomic_cas:
  	
+ 	! "cas" only works on sparcv9 chips, and requies a compiler
+ 	! that is targeting sparcv9.  It will fail on a compiler
+ 	! targeting sparcv8, and of course will not be understood
+ 	! by a sparcv8 CPU.  If this fails on existing Solaris
+ 	! systems, we need to use a !defined(__sparcv9) test
+ 	! to fall back to the old "ldstub" call for sparcv8 compiles.
+ 	! gcc continues to use "ldstub" because there is no indication
+ 	! which sparc version it is targeting.
+ 	!
+ 	! There actually is a trick for embedding "cas" for a compiler
+ 	! that is targeting sparcv8:
+ 	!
+ 	!   http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/sparc/threads/sparc.il
+ 	!
+ 	! This might work for sparc8:
+ 	! ldstub [%o0],%o1	! moves only a byte
+ 
  	cas     [%o0],%o2,%o1
  	mov     %o1,%o0
  	retl
Index: src/include/storage/s_lock.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/s_lock.h,v
retrieving revision 1.152
diff -c -c -r1.152 s_lock.h
*** src/include/storage/s_lock.h	29 Apr 2006 11:55:19 -0000	1.152
--- src/include/storage/s_lock.h	17 May 2006 23:43:03 -0000
***************
*** 311,316 ****
--- 311,320 ----
  {
  	register slock_t _res;
  
+ 	/*
+ 	 *	See comment in /pg/backend/port/tas/solaris_sparc.s for why this
+ 	 *	uses "ldstub", and that file uses "cas".
+ 	 */
  	__asm__ __volatile__(
  		"	ldstub	[%2], %0	\n"
  :		"=r"(_res), "+m"(*lock)