[Openmp-dev] (no subject)

Jack Howarth howarth.mailing.lists at gmail.com
Fri May 30 21:18:22 PDT 2014 

Hal,
     Actually, this needs some additional work to truly mimic the 'make
compiler=clang; build. We need additional add_custom_command's to handle
this bit…

----- 1/1 --- kmp_dummy.c -----
echo "void __kmp_dummy() {}" > kmp_dummy.c
----- 1/1 --- kmp_dummy.o -----
clang -I ./ -I ../../src/ -I ../../src/i18n/ -I ../../src/include/40/ -I
../../src/thirdparty/ittnotify/ -D USE_ITT_BUILD -D NDEBUG -D
KMP_ARCH_STR="\"Intel(R) 64\"" -D _GNU_SOURCE -D _REENTRANT -D
KMP_USE_ASSERT -D BUILD_I8 -D BUILD_TV -D
KMP_LIBRARY_FILE=\"libiomp5.dylib\" -D KMP_VERSION_MAJOR=5 -D CACHE_LINE=64
-D KMP_ADJUST_BLOCKTIME=1 -D BUILD_PARALLEL_ORDERED -D KMP_ASM_INTRINS -D
USE_LOAD_BALANCE -D USE_CBLKDATA -D GUIDEDLL_EXPORTS -D KMP_GOMP_COMPAT -D
KMP_USE_ADAPTIVE_LOCKS=1 -D KMP_DEBUG_ADAPTIVE_LOCKS=0 -D OMP_50_ENABLED=0
-D OMP_41_ENABLED=0 -D OMP_40_ENABLED=1 -D OMP_30_ENABLED=1 -D
USE_ITT_NOTIFY=1 -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_ -I/sw/include -c
-fPIC -O2 -Wno-unused-value -Wno-switch -Wno-deprecated-register
-fno-exceptions -x c++ -std=c++0x  -o kmp_dummy.o kmp_dummy.c
----- 1/1 --- external-objects.lst -----
perl ../../tools/required-objects.pl --os=mac --arch=32e \
        --base ittnotify_static.o kmp_affinity.o kmp_alloc.o kmp_atomic.o
kmp_cancel.o kmp_csupport.o kmp_debug.o kmp_dispatch.o kmp_environment.o
kmp_error.o kmp_ftn_cdecl.o kmp_ftn_extra.o kmp_global.o kmp_gsupport.o
kmp_i18n.o kmp_io.o kmp_itt.o kmp_lock.o kmp_runtime.o kmp_sched.o
kmp_settings.o kmp_str.o kmp_taskdeps.o kmp_tasking.o kmp_taskq.o
kmp_threadprivate.o kmp_utility.o kmp_version.o z_Linux_asm.o
z_Linux_util.o kmp_dummy.o --extra  --print-extra > external-objects.lst.tmp
warning: nm: no name list
echo "kmp_dummy.o" >> external-objects.lst.tmp
mv external-objects.lst.tmp external-objects.lst
----- 1/1 --- external-symbols.lst -----
nm -goj $(cat external-objects.lst) > external-symbols.lst.0.tmp
cut -f2 -d" " external-symbols.lst.0.tmp > external-symbols.lst.1.tmp
mv external-symbols.lst.1.tmp external-symbols.lst
----- 1/1 --- iomp.o -----
ld -r -unexported_symbols_list external-symbols.lst \
        -non_global_symbols_strip_list external-symbols.lst \
        -filelist external-objects.lst \
        -o iomp.o ittnotify_static.o kmp_affinity.o kmp_alloc.o
kmp_atomic.o kmp_cancel.o kmp_csupport.o kmp_debug.o kmp_dispatch.o
kmp_environment.o kmp_error.o kmp_ftn_cdecl.o kmp_ftn_extra.o kmp_global.o
kmp_gsupport.o kmp_i18n.o kmp_io.o kmp_itt.o kmp_lock.o kmp_runtime.o
kmp_sched.o kmp_settings.o kmp_str.o kmp_taskdeps.o kmp_tasking.o
kmp_taskq.o kmp_threadprivate.o kmp_utility.o kmp_version.o z_Linux_asm.o
z_Linux_util.o
----- 1/1 --- unstripped/.dir -----
mkdir -p unstripped/
touch unstripped/.dir
----- 1/1 --- unstripped/libiomp5.dylib.lst -----
echo iomp.o  > unstripped/libiomp5.dylib.lst

I'll see if I can puzzle that out on darwin over the weekend.
                 Jack
ps IMHO, we should try to have the cmake build follow the same exact steps
as the 'make compiler=clang' build to maintain continuity.


On Fri, May 30, 2014 at 11:46 PM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

> Hal,
>        The attached Cmakefiles.txt, for placement in openmp/runtime/src,
> is as simple as I think the file can be and still reproduce the build
> obtained from build.pl with 'make compiler=clang'.
> Between the syntax required for the perl scripts in the tools subdirectory
> and the syntax requirements of cmake, I don't see this changing much.
> Everything in there is essential to the build. For instance, if you drop….
>
> set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)
> set_source_files_properties(${ASM_SOURCES} PROPERTIES LANGUAGE CXX)
>
> you will get compile time errors in clang for z_Linux_util.c on darwin
> which wants to use a c++ compiler here.
>              Jack
>
>
> On Fri, May 30, 2014 at 8:13 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> Jack,
>>
>> No, I based my makefile on a manual examination of the various .mk files
>> in the runtime/src directory (+ some trial and error). It is for a port of
>> the library to a ppc64-based system, so you'll need to make some changes
>> (like adding back the asm file) to make it work on Darwin.
>>
>>  -Hal
>>
>> ----- Original Message -----
>> > From: "Jack Howarth" <howarth.mailing.lists at gmail.com>
>> > To: "Hal Finkel" <hfinkel at anl.gov>
>> > Cc: openmp-dev at dcs-maillist2.engr.illinois.edu, "C. Bergström" <
>> cbergstrom at pathscale.com>
>> > Sent: Friday, May 30, 2014 7:04:59 PM
>> > Subject: Re: [Openmp-dev] (no subject)
>> >
>> >
>> > Hal,
>> > Did you base your Makefile on the behavior of build.pl from 'make
>> > compiler=gcc'? On darwin, I find that the exact build as replicated
>> > from the behavior of build.pl using 'make compiler=clang' produces a
>> > different object file list….
>> >
>> >
>> >
>> > --- Makefile.bgq 2014-05-30 19:59:16.000000000 -0400
>> > +++ Makefile.jwh 2014-05-30 20:01:08.000000000 -0400
>> > @@ -7,10 +7,10 @@
>> >
>> > CPPFLAGS = ${FEATURE_FLAGS} -D__float128='long double'
>> >
>> > -CC = powerpc64-bgq-linux-gcc
>> > -CXX = powerpc64-bgq-linux-g++
>> > +CC = clang
>> > +CXX = clang++
>> >
>> > -all: build/libiomp5.a build/libiomp5.so
>> > +all: build/libiomp5.a build/libiomp5.dylib
>> >
>> > build/.dir:
>> > mkdir -p build
>> > @@ -28,6 +28,7 @@
>> > ${CC} -x c++ -c ${CPPFLAGS} -g -O3 -Isrc -Ibuild -o $@ $<
>> >
>> > OBJS = build/kmp_alloc.o \
>> > + build/kmp_affinity.o \
>> > build/kmp_atomic.o \
>> > build/kmp_cancel.o \
>> > build/kmp_csupport.o \
>> > @@ -37,8 +38,8 @@
>> > build/kmp_error.o \
>> > build/kmp_ftn_cdecl.o \
>> > build/kmp_ftn_extra.o \
>> > - build/kmp_ftn_stdcall.o \
>> > build/kmp_global.o \
>> > + build/kmp_gsupport.o \
>> > build/kmp_i18n.o \
>> > build/kmp_io.o \
>> > build/kmp_itt.o \
>> > @@ -53,7 +54,8 @@
>> > build/kmp_utility.o \
>> > build/kmp_version.o \
>> > build/kmp_lock.o \
>> > - build/z_Linux_util.o
>> > + build/z_Linux_util.o \
>> > + build/ittnotify_static.o
>> >
>> > BGSYS_FLOOR=$(shell readlink /bgsys/drivers/ppcfloor)
>> > build/libiomp5.so: $(OBJS)
>> > [prrg4:~/llvm-svn/openmp-3.5.0/runtime] howarth%
>> >
>> >
>> >
>> >
>> >
>> > On Fri, May 30, 2014 at 7:30 PM, Hal Finkel < hfinkel at anl.gov >
>> > wrote:
>> >
>> >
>> >
>> > ----- Original Message -----
>> > > From: "Jack Howarth" < howarth.mailing.lists at gmail.com >
>> >
>> > > To: "Hal Finkel" < hfinkel at anl.gov >
>> > > Cc: openmp-dev at dcs-maillist2.engr.illinois.edu , "C. Bergström" <
>> > > cbergstrom at pathscale.com >
>> >
>> > > Sent: Friday, May 30, 2014 6:21:19 PM
>> > > Subject: Re: [Openmp-dev] (no subject)
>> > >
>> > >
>> >
>> > > Hal,
>> > > Also note that they are replicating the build from build.pl down to
>> > > the exact order of source file compilation. So the question arises,
>> > > to what degree is is it invalid to even glance at their
>> > > Cmakelist.txt for overall ideas on how to do this. Considering that
>> > > they are simply emitting the same build commands as build.pl (to
>> > > which we already have license), I imagine we would have to code in
>> > > a
>> > > very similar manner even if done from scratch, i.e., use instances
>> > > of add_custom_command to manually emit the same build.pl commands.
>> > > There probably aren't that many ways to code that in cmake.
>> > > Jack
>> >
>> > Yep, I understand. That's why what you did could be considered
>> > imprudent ;) -- In any case, let's give C. a chance to solve this
>> > problem for you.
>> >
>> > In case that does not work out and it makes things easier, I've
>> > attached another alternate makefile that I use to build this
>> > library. Converting this into cmake form is also not too hard.
>> >
>> > -Hal
>> >
>> >
>> > >
>> > >
>> > >
>> > > On Fri, May 30, 2014 at 7:10 PM, Jack Howarth <
>> > > howarth.mailing.lists at gmail.com > wrote:
>> > >
>> > >
>> > >
>> > > Hal,
>> > > Even if that is problematic, starting over is fairly
>> > > straight-forward. Their CMakelists.txt is simply a directly
>> > > repetition of the commands emitted from the build as done by
>> > > build.pl . So if they are difficult about it, just take a printout
>> >
>> >
>> > > of the output for the current build with 'make compiler=clang" and
>> > > code the Cmakelist.txt from that. If you look carefully, you will
>> > > see that they are replicating this down to the exact order of the
>> > > parameters on the compiler calls. It is very difficult to see how
>> > > that could be intellectual property in any fashion since
>> > > replicating
>> > > the output of the build.pl currently in llvm.org 's openmp results
>> > > in the same ordering. Note that their files are only a crude
>> > > starting point and nowhere near what we will need for llvm.
>> > > Jack
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, May 30, 2014 at 6:40 PM, Hal Finkel < hfinkel at anl.gov >
>> > > wrote:
>> > >
>> > >
>> > > Jack,
>> > >
>> > > Before you go too far with this, do we have Pathscale's explicit
>> > > contribution of their build files? (I've cc'd C. Bergstrom so that
>> > > he can comment directly).
>> > >
>> > > Thanks,
>> > > Hal
>> > >
>> > >
>> > >
>> > > ----- Original Message -----
>> > > > From: "Jack Howarth" < howarth.mailing.lists at gmail.com >
>> > > > To: openmp-dev at dcs-maillist2.engr.illinois.edu
>> > > > Sent: Friday, May 30, 2014 5:28:33 PM
>> > > > Subject: [Openmp-dev] (no subject)
>> > > >
>> > > >
>> > > >
>> > > > Attached is a first pass at modifying the cmakefiles from
>> > > > https://github.com/pathscale/openmprtl/blob/master/itt/libomp_oss
>> > > > to
>> > > > build openmp. I noticed that the existing build.pl doesn't
>> > > > actually
>> > > > build a fat shared library on darwin. The attached changes can
>> > > > does
>> > > > this in an indirect fashion with…
>> > > >
>> > > >
>> > > > % cd runtime
>> > > > % mkdir build_32
>> > > > % cd build_32
>> > > > % cmake -DARCH="32" ..
>> > > > % make VERBOSE=1
>> > > > % cd ..
>> > > > % mkdir build_32e
>> > > > % cmake -DARCH="32e" ..
>> > > > % make VERBOSE=1
>> > > > % cd ..
>> > > > % lipo ./build_32/src/libiomp5.dylib
>> > > > ./build_32e/src/libiomp5.dylib
>> > > > -create -o libiomp5.dylib
>> > > > % file libiomp5.dylib
>> > > >
>> > > > libiomp5.dylib: Mach-O universal binary with 2 architectures
>> > > > libiomp5.dylib (for architecture x86_64): Mach-O 64-bit
>> > > > dynamically
>> > > > linked shared library x86_64
>> > > > libiomp5.dylib (for architecture i386): Mach-O dynamically linked
>> > > > shared library i386
>> > > >
>> > > >
>> > > > Normally we could do this in cmake by passing '-arch i386 -arch
>> > > > x86_64' but use of assembly code in the build gums that up.
>> > > > _______________________________________________
>> > > > Openmp-dev mailing list
>> > > > Openmp-dev at dcs-maillist2.engr.illinois.edu
>> > > > http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>> > > >
>> > >
>> > > --
>> > > Hal Finkel
>> > > Assistant Computational Scientist
>> > > Leadership Computing Facility
>> > > Argonne National Laboratory
>> > >
>> > >
>> > >
>> >
>> > --
>> > Hal Finkel
>> > Assistant Computational Scientist
>> > Leadership Computing Facility
>> > Argonne National Laboratory
>> >
>> >
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20140531/822c7217/attachment.html>

More information about the Openmp-dev mailing list