UPC runtime: process config.h.cmake for each libupc runtime variant

[swatanabe]

I am in the process of upgrading the UPC runtime to the latest version in GUPC. That version has support for inter-node communications via a networking API called "portals4". It is enabled via a configure option. The choices are: (1) the current 'smp' runtime, or (2) the 'portals4' runtime. At some point in the future, we might try to unify these runtimes. Another improvement is re-licensing from FSF-assigned GPL licensing to BSD-licensing.

As a first cut, I copied over the new files, tweaked CMakelists.txt by adding the new 'smp' files to LIBUPC_SOURCES. I also copied the new 'config.h.in' onto 'config.h.make'. This, however, led to some build issues. The important diff's follow.

46a64,69

/* Whether UPC pointers-to-shared use the 'packed' representation */

undef GUPCR_PTS_PACKED_REP

/* Size of shared pointer's phase field (in bits) */

undef GUPCR_PTS_PHASE_SIZE

49a73,78
/* Whether UPC shared pointers use the 'struct' representation */

undef GUPCR_PTS_STRUCT_REP

/* Size of shared pointer's thread field (in bits) */

undef GUPCR_PTS_THREAD_SIZE

52a82,87
/* Whether the 'vaddr' field comes first (ie, [[vaddr,thread,phase]]) */

undef GUPCR_PTS_VADDR_FIRST

/* Size of shared pointer's vaddr field (in bits) */

undef GUPCR_PTS_VADDR_SIZE

57c92,95

< #define GUPCR_TREE_FANOUT @UPC_TREE_FANOUT@

undef GUPCR_TREE_FANOUT

/* Define to 1 if UPC runtime will use Portals4 triggered operations. */

undef GUPCR_USE_PORTALS4_TRIGGERED_OPS

After reading through the cmake logic, it seems that the version of config.h that is created from 'config.h.cmake' is built at the top-level of the libupc build structure, but is not built for each {packed,struct}-pts,{first,last}-vaddr variant. The variants pick up their values of 'GUPCR_PTS_PACKED_REP', etc. from the 'COMPILER_DEFINITIONS' property:

set_property(TARGET ${lib_name} PROPERTY COMPILE_DEFINITIONS ${lib_defs})

Then, for the runtime sources written 'upc', there is this logic in 'smp/upc-lib.in':

ifdef UPC_PTS_PACKED_REP

define GUPCR_PTS_PACKED_REP 1

elif defined(UPC_PTS_STRUCT_REP)

define GUPCR_PTS_STRUCT_REP 1

endif

The logic above is a divergence from the logic in the GUPC runtime, because there 'config.h.in' is customized by configure for each runtime variant.

Is the above summary correct?

In the short term, I can remove the explicit #undef of the various shared pointer format related definitions and let the existing cmake logic take care of it, but I am wondering if the logic might be reworked to be more similar to the method used by GUPC?

In a related matter, as shown in the diff's above, there is the cmake substitution that I need to bring back:

define GUPCR_TREE_FANOUT @UPC_TREE_FANOUT@

In general, however, there appear to be many few configuration-related definitions that are either tested by 'cmake' or that might be provided as cmake parameters. (I don't know the syntax for setting those parameters, however.) In particular, the portals4 runtime introduces some new configuration parameters. For example,

40a25,36

/* Size of get/put bounce buffer */

undef GUPCR_BOUNCE_BUFFER_SIZE

/* upc_global_exit() timeout in seconds. */

undef GUPCR_GLOBAL_EXIT_TIMEOUT

/* Define to 1 if UPC runtime checks are supported. */

undef GUPCR_HAVE_CHECKS

/* Define to 1 if UPC runtime debugging mode is enabled. */

undef GUPCR_HAVE_DEBUG

43a40,60
/* Define to 1 if UPC runtime statistics collection is supported. */

undef GUPCR_HAVE_STATS

/* Define to 1 if UPC runtime tracing is supported. */

undef GUPCR_HAVE_TRACE

/* Maximum number of locks held per thread */

undef GUPCR_MAX_LOCKS

/* Define to 1 if UPC runtime will use node local memory accesses. */

undef GUPCR_NODE_LOCAL_MEM

/* Define to 1 if UPC node local access uses mmap-ed file. */

undef GUPCR_NODE_LOCAL_MEM_MMAP

/* Define to 1 if UPC node local access uses Posix shared memory. */

undef GUPCR_NODE_LOCAL_MEM_POSIX

/* Portals4 PTE base index. */

undef GUPCR_PTE_BASE

Summarizing:

1. I'd like to move the shared pointer characteristics back into config.h and have config.h customized for each runtime variant. Is that feasible?
2. I'd like it config.h.cmake produced the same definitions as found in GUPC's config.h.in both in the configuration tests it runs and also by providing similar configuration-specific parameters.

When using cmake, is it sometimes possible to actually run configure as a way of making configuration tests? Or does cmake have another way of implementing configure-like checks?
Add

Subtasks
Add

Related issues

Issue #
Delay: days Cancel
History
#1

Updated by John Wiegley 3 months ago

* Assignee set to Steven Watanabe

#2

Updated by Gary Funck 3 months ago
Comment

I recently merged the current GUPC libgupc runtime into the Clang UPC runtime. Most of the problems encountered relate to the fact that config.h is not fully processed via configure and is not instantiated for each runtime variant.

This web page summarizes the key differences:
[[http://gccupc.org/clang-upc-runtime-mods/]]

While going through the process of updating the runtime, I discovered a couple other differences that I will summarize here, but that might be logically separated out into other issues.

1. In GUPC, there is a file named gcc-upc-lib.in that is pre-processed by a script to produce a header file, gcc-upc-lib.h . However, in Clang it is renamed to upc-lib.in and then pre-processed into upc-lib.h.
2. In GUPC, gcc-upc-lib.h is #included from a file named include/gcc-upc.h. In GUPC, gcc-upc.h is pre-included by the gupc command.
3. In Clang UPC, gcc-upc.h appears to be un-used.
4. In Clang UPC, upc-lib.h is pre-included by the clang command when compiling UPC programs, only when the driver has determined that the runtime should be inlined.

Thus in addition to fully processing config.h.in and customizing it to each runtime variant, it appears that gcc-upc.h should be unconditionally pre-included (as this is the way that gupc works). This in turn will include gcc-upc-lib.h.

A note regarding the rename of gcc-upc-lib.in to upc-lib.in: Although there is some logic in doing that, it does make the task of tracking changes between gupc and clang upc more difficult.
#3

Updated by Steven Watanabe 3 months ago
Comment

1. I'm not sure that moving the #defines back into config.h will help.
   The real problem is that you're trying to use the same file for
   config.h.in and config.h.cmake. Unfortunately, CMake uses a different
   syntax than autoconf, so this isn't really going to work.

2. CMake has its own method of running configuration tests. I just didn't implement it, because it worked without on the platforms we tested with. I don't know of a way for CMake to use the autotools script (It may be possible, but I doubt that there's an easy way--running configure and parsing the output doesn't seem like a very good idea.).
   UPC runtime (libupc) build failure with newer cmake (2.8.10.2) #4

   Updated by Gary Funck 3 months ago

   • Priority changed from Normal to Urgent
     OSX: make fails with unrecognized command line option "-Wcovered-switch-default" #5

Updated by Steven Watanabe 3 months ago

* Status changed from New to In Progress

#6

Updated by Steven Watanabe 2 months ago
Comment

The following macros in config.h are apparently unused. I'm assuming that it's okay just to remove them.

HAVE_AS_SYMVER_DIRECTIVE
HAVE_ATTRIBUTE_ALIAS
HAVE_ATTRIBUTE_DLLEXPORT
HAVE_ATTRIBUTE_VISIBILITY
HAVE_BACKTRACE
HAVE_BACKTRACE SYMBOLS
HAVE_BACKTRACE_SYMBOLS_FD
HAVE_BROKEN_POSIX_SEMAPHORES
HAVE_CC_TLS
HAVE_DECL_SYS_SIGLIST
HAVE_DLFCN_H
HAVE_FCNTL_H
HAVE_FORK
HAVE_FTRUNCATE
HAVE_GETCWD
HAVE_GETHOSTBYNAME
HAVE_GETLOADAVG
HAVE_GETPAGESIZE
HAVE_GTHR_DEFAULT
HAVE_INTTYPES_H
HAVE_MALLOC
HAVE_MEMORY_H
HAVE_MEMSET
HAVE_MKDIR
HAVE_MMAP
HAVE_MUNMAP
HAVE_NETDB_H
HAVE_NETINET_IN_H
HAVE_PTHREAD_AFFINITY_NP
HAVE_PTRDIFF_T
HAVE_SCHED_H
HAVE_SEMAPHORE_H
HAVE_SOCKET
HAVE_STAT_EMPTY_STRING_BUG
HAVE_STDDEF_H
HAVE_STDINT_H
HAVE_STDLIB_H
HAVE_STRCASECMP
HAVE_STRDUP
HAVE_STRERROR
HAVE_STRINGS_H
HAVE_STRING_H
HAVE_STRTOL
HAVE_STRTOULL
HAVE_SYNC_BUILTINS
HAVE_SYS_LOADAVG_H
HAVE_SYS_SOCKET_H
HAVE_SYS_STAT_H
HAVE_SYS_TYPES_H
HAVE_TYPE_WAIT_H
HAVE_TLS
HAVE_UNISTD_H
HAVE_VFORK
HAVE_VFORK_H
HAVE_WORKING_FORK
HAVE_WORKING_VFORK
LIBGUPC_GNU_SYMBOL_VERSIONING
LSTAT_FOLLOWS_SLASHED_SYMLINK
LT_OBJDIR
PACKAGE
PACKAGE_NAME
PACKAGE_STRING
PACKAGE_TARNAME
PACKAGE_URL
PACKAGE_VERSION
SIZEOF_CHAR
SIZEOF_INT
SIZEOF_LONG
SIZEOF_SHORT
SIZEOF_VOID_P
STDC_HEADERS
STRING_WITH_STRINGS
VERSION
#7

Updated by Gary Funck 2 months ago
Comment

Steven Watanabe wrote:

The following macros in config.h are apparently unused.
I'm assuming that it's okay just to remove them.

Yes. That's OK. We have a tendency to add (or inherit) autoconf tests that we don't use.
#8

Updated by Steven Watanabe 2 months ago
Comment

Where can I find portals4?
#9

Updated by Steven Watanabe 2 months ago
Comment

I'm not sure that specializing config.h for each build variant is feasible.
config.h is one of the sources for gcc-upc-lib.h, and I'd really rather avoid specializing gcc-upc-lib.h as this would mean extra logic to #include the correct file depending on the compiler options.
#10

Updated by Gary Funck 2 months ago
Comment

Steven Watanabe wrote:

Where can I find portals4?

I will send you a "how to" under separate cover.
#11

Updated by Gary Funck 2 months ago
Comment

Steven Watanabe wrote:

I'm not sure that specializing config.h for each build variant is feasible.
config.h is one of the sources for gcc-upc-lib.h, and I'd really rather avoid specializing gcc-upc-lib.h as this would mean extra logic to #include the correct file depending on the compiler options.

We may need to discuss this in a telecon, so that I can be sure that I understand the issues.

However we do it, the goal is for the libgupc runtime sources (the non-make/config related files) to match those in the clang libupc directory. I don't think that Intrepid wants to use the approach used in the clang runtime, but perhaps there is a middle ground some where.