Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 123c9d2

Browse files
committed
Clean up icc + ia64 situation.
Some googling turned up multiple sources saying that older versions of icc do not accept gcc-compatible asm blocks on IA64, though asm does work on x86[_64]. This is apparently fixed as of icc version 12.0 or so, but that doesn't help us much; if we have to carry the extra implementation anyway, we may as well just use it for icc rather than add a compiler version test. Hence, revert commit 2c713d6 (though I separated the icc code from the gcc code completely, producing what seems cleaner code). Document the state of affairs more explicitly, both in s_lock.h and postgres.c, and make some cosmetic adjustments around the IA64 code in s_lock.h.
1 parent 049a779 commit 123c9d2

File tree

2 files changed

+26
-13
lines changed

2 files changed

+26
-13
lines changed

src/backend/tcop/postgres.c

+9-1
Original file line numberDiff line numberDiff line change
@@ -2998,15 +2998,23 @@ ProcessInterrupts(void)
29982998
* IA64-specific code to fetch the AR.BSP register for stack depth checks.
29992999
*
30003000
* We currently support gcc, icc, and HP-UX's native compiler here.
3001+
*
3002+
* Note: while icc accepts gcc asm blocks on x86[_64], this is not true on
3003+
* ia64 (at least not in icc versions before 12.x). So we have to carry a
3004+
* separate implementation for it.
30013005
*/
30023006
#if defined(__ia64__) || defined(__ia64)
30033007

30043008
#if defined(__hpux) && !defined(__GNUC__) && !defined(__INTEL_COMPILER)
30053009
/* Assume it's HP-UX native compiler */
30063010
#include <ia64/sys/inline.h>
30073011
#define ia64_get_bsp() ((char *) (_Asm_mov_from_ar(_AREG_BSP, _NO_FENCE)))
3012+
#elif defined(__INTEL_COMPILER)
3013+
/* icc */
3014+
#include <asm/ia64regs.h>
3015+
#define ia64_get_bsp() ((char *) __getReg(_IA64_REG_AR_BSP))
30083016
#else
3009-
/* Use inline assembly; works with gcc and icc */
3017+
/* gcc */
30103018
static __inline__ char *
30113019
ia64_get_bsp(void)
30123020
{

src/include/storage/s_lock.h

+17-12
Original file line numberDiff line numberDiff line change
@@ -266,6 +266,10 @@ spin_delay(void)
266266
* any explicit statement on that in the gcc manual. In Intel's compiler,
267267
* the -m[no-]serialize-volatile option controls that, and testing shows that
268268
* it is enabled by default.
269+
*
270+
* While icc accepts gcc asm blocks on x86[_64], this is not true on ia64
271+
* (at least not in icc versions before 12.x). So we have to carry a separate
272+
* compiler-intrinsic-based implementation for it.
269273
*/
270274
#define HAS_TEST_AND_SET
271275

@@ -303,6 +307,10 @@ tas(volatile slock_t *lock)
303307
return ret;
304308
}
305309

310+
/* icc can't use the regular gcc S_UNLOCK() macro either in this case */
311+
#define S_UNLOCK(lock) \
312+
do { __memory_barrier(); *(lock) = 0; } while (0)
313+
306314
#endif /* __INTEL_COMPILER */
307315
#endif /* __ia64__ || __ia64 */
308316

@@ -671,22 +679,19 @@ typedef unsigned char slock_t;
671679
#endif
672680

673681
/*
674-
* Note that this implementation is unsafe for any platform that can speculate
682+
* Default implementation of S_UNLOCK() for gcc/icc.
683+
*
684+
* Note that this implementation is unsafe for any platform that can reorder
675685
* a memory access (either load or store) after a following store. That
676-
* happens not to be possible x86 and most legacy architectures (some are
686+
* happens not to be possible on x86 and most legacy architectures (some are
677687
* single-processor!), but many modern systems have weaker memory ordering.
678-
* Those that do must define their own version S_UNLOCK() rather than relying
679-
* on this one.
688+
* Those that do must define their own version of S_UNLOCK() rather than
689+
* relying on this one.
680690
*/
681691
#if !defined(S_UNLOCK)
682-
#if defined(__INTEL_COMPILER)
683-
#define S_UNLOCK(lock) \
684-
do { __memory_barrier(); *(lock) = 0; } while (0)
685-
#else
686692
#define S_UNLOCK(lock) \
687693
do { __asm__ __volatile__("" : : : "memory"); *(lock) = 0; } while (0)
688694
#endif
689-
#endif
690695

691696
#endif /* defined(__GNUC__) || defined(__INTEL_COMPILER) */
692697

@@ -793,7 +798,7 @@ tas(volatile slock_t *lock)
793798

794799
#if defined(__hpux) && defined(__ia64) && !defined(__GNUC__)
795800
/*
796-
* HP-UX on Itanium, non-gcc compiler
801+
* HP-UX on Itanium, non-gcc/icc compiler
797802
*
798803
* We assume that the compiler enforces strict ordering of loads/stores on
799804
* volatile data (see comments on the gcc-version earlier in this file).
@@ -816,7 +821,7 @@ typedef unsigned int slock_t;
816821
#define S_UNLOCK(lock) \
817822
do { _Asm_mf(); (*(lock)) = 0; } while (0)
818823

819-
#endif /* HPUX on IA64, non gcc */
824+
#endif /* HPUX on IA64, non gcc/icc */
820825

821826
#if defined(_AIX) /* AIX */
822827
/*
@@ -935,7 +940,7 @@ extern int tas_sema(volatile slock_t *lock);
935940
#if !defined(S_UNLOCK)
936941
/*
937942
* Our default implementation of S_UNLOCK is essentially *(lock) = 0. This
938-
* is unsafe if the platform can speculate a memory access (either load or
943+
* is unsafe if the platform can reorder a memory access (either load or
939944
* store) after a following store; platforms where this is possible must
940945
* define their own S_UNLOCK. But CPU reordering is not the only concern:
941946
* if we simply defined S_UNLOCK() as an inline macro, the compiler might

0 commit comments

Comments
 (0)