Git Product home page Git Product logo

clangupc / llvm-upc Goto Github PK

View Code? Open in Web Editor NEW

This project forked from llvm-mirror/llvm

7.0 7.0 3.0 713.3 MB

Low Level Virtual Machine (LLVM) for Clang UPC(2C)

Home Page: https://clangupc.github.io/

License: Other

CMake 0.19% Makefile 0.01% Shell 0.04% C 0.32% OCaml 0.11% Python 0.36% C++ 30.46% Objective-C 0.01% Assembly 19.44% LLVM 48.99% Perl 0.01% Emacs Lisp 0.01% Go 0.05% Batchfile 0.01% Roff 0.01% CSS 0.01% NASL 0.01% HTML 0.01% Swift 0.01% Starlark 0.01%

llvm-upc's People

Contributors

ahatanak avatar arsenm avatar asl avatar atrick avatar bob-wilson avatar chandlerc avatar chapuni avatar cunningbaldrick avatar d0k avatar ddunbar avatar dexonsmith avatar dsandersllvm avatar dwblaikie avatar echristo avatar espindola avatar isanbard avatar lattner avatar lhames avatar majnemer avatar mbrukman avatar nlewycky avatar resistor avatar rksimon avatar rnk avatar rotateright avatar stoklund avatar tnorthover avatar topperc avatar tstellaramd avatar zmodem avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

llvm-upc's Issues

UPC-IR: atomic store operand must be power-of-two byte-sized integer

I am getting the following error on test29:

atomic store operand must be power-of-two byte-sized integer
  store atomic i80 %2, i80 addrspace(16)* inttoptr (i64 or (i64 and (i64 lshr (i64 shl (i64 sub (i64 ptrtoint (x86_fp80* @xA1 to i64), i64 ptrtoint (i8* @__upc_shared_start to i64)), i64 30), i64 20), i64 1023), i64 shl (i64 lshr (i64 shl (i64 sub (i64 ptrtoint (x86_fp80* @xA1 to i64), i64 ptrtoint (i8* @__upc_shared_start to i64)), i64 30), i64 30), i64 20)) to i80 addrspace(16)*) seq_cst, align 16, !dbg !43

I was wondering if it makes sense to disable these kind of errors if atimic is into the UPC address space, as atomic operation will never be executed. The same with floats, etc..

Build failure (unittests) on Solaris

On Solaris I see the errors an the bottom of the posting.
Clearly this is because something has defined isnan and isinf to their __builtin-prefixed equivalents.
That "something" is the math.h header, and there is nothing I can see to prevent that definition.

So, I think something like the following is needed:

#undef isnan
#undef isinf

but I am totally uncertain where that should be added.

Related:
Since I am using configure (not cmake) on the Solaris systems, I don't see a way to disable building the unit tests.
I do not recall at the moment why I am not using cmake, but I did install cmake-2.8.6 so there must be a reason I chose not to use it.

-Paul

llvm[2]: Compiling APFloatTest.cpp for Release+Asserts build
In file included from /export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/gtest.h:57:0,
                 from /export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:15:
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp: In member function 'virtual void {anonymous}::APFloatTest_roundToIntegral_Test::TestBody()':
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1309:15: error: '__builtin_isnan' is not a member of 'std'
   EXPECT_TRUE(std::isnan(P.convertToDouble()));
               ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:1208:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1309:3: note: in expansion of macro 'EXPECT_TRUE'
   EXPECT_TRUE(std::isnan(P.convertToDouble()));
   ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1309:15: note: suggested alternative:
   EXPECT_TRUE(std::isnan(P.convertToDouble()));
               ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:1208:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1309:3: note: in expansion of macro 'EXPECT_TRUE'
   EXPECT_TRUE(std::isnan(P.convertToDouble()));
   ^
<built-in>:0:0: note:   '__builtin_isnan'
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1312:15: error: '__builtin_isinf' is not a member of 'std'
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() > 0.0);
               ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:1208:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1312:3: note: in expansion of macro 'EXPECT_TRUE'
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() > 0.0);
   ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1312:15: note: suggested alternative:
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() > 0.0);
               ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:1208:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1312:3: note: in expansion of macro 'EXPECT_TRUE'
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() > 0.0);
   ^
<built-in>:0:0: note:   '__builtin_isinf'
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1315:15: error: '__builtin_isinf' is not a member of 'std'
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() < 0.0);
               ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:1208:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1315:3: note: in expansion of macro 'EXPECT_TRUE'
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() < 0.0);
   ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1315:15: note: suggested alternative:
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() < 0.0);
               ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:1208:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^
/export/home/phargrov/upcnightly-32/llvm-upc/src/unittests/ADT/APFloatTest.cpp:1315:3: note: in expansion of macro 'EXPECT_TRUE'
   EXPECT_TRUE(std::isinf(P.convertToDouble()) && P.convertToDouble() < 0.0);
   ^
<built-in>:0:0: note:   '__builtin_isinf'
/usr/gnu/bin/rm: cannot remove '/export/home/phargrov/upcnightly-32/llvm-upc/bld/unittests/ADT/Release+Asserts/APFloatTest.d.tmp': No such file or directory
gmake[2]: *** [/export/home/phargrov/upcnightly-32/llvm-upc/bld/unittests/ADT/Release+Asserts/APFloatTest.o] Error 1

Build failure on OpenBSD-5.6

My builds on OpenBSD are now failing as follows:

llvm[1]: Compiling Watchdog.cpp for Release+Asserts build
In file included from /home/phargrov/upcnightly/llvm-upc/src/lib/Support/Unix/Watchdog.inc:15:0,
                 from /home/phargrov/upcnightly/llvm-upc/src/lib/Support/Watchdog.cpp:19:
/usr/include/unistd.h:527:18: error: 'fd_set' has not been declared
 int  select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
                  ^
/usr/include/unistd.h:527:28: error: 'fd_set' has not been declared
 int  select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
                            ^
/usr/include/unistd.h:527:38: error: 'fd_set' has not been declared
 int  select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
                                      ^

A recent man page for select() says

/* According to POSIX.1-2001 */
#include <sys/select.h>

/* According to earlier standards */
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

And it looks like the "earlier standards" incantation does not work on OpenBSD-5.6.

Since there is no HAVE_SYS_SELECT_H token in include/llvm/Config/config.h yet, I am not prepared to make the necessary changes on my own. However, I've confirmed that including sys/select.h works.

UPC-IR: parametrize Remote Pointer (RP)

At this point the remote pointer in IR is 64-bit quantity with 44 bits allocated for the address (offset) and 20 bits for the thread number.

Add configuration options so we can change these values.

Build failure on NetBSD-6.1.5

My builds on NetBSD now fail with:

[  7%] Building CXX object utils/TableGen/CMakeFiles/llvm-tblgen.dir/CTagsEmitter.cpp.o
Linking CXX executable ../../bin/llvm-tblgen
[  7%] Built target llvm-tblgen
[  7%] Building Intrinsics.gen...
execname not specified in AUX vector: No such file or directory

The "execname..." error is coming from the llvm-tblgen command linked just before.

UPC-IR: typed runtime interface

At the beginning, I think the idea was to convert RP pointer into the UPC pointer before we call the runtime. This way we can have only one interface. But I see that this is not that useful as the interface is very simple and there is no point in generation the code of putting it back to the form fo rthe purpose of the AP only (we do not use phase in the runtime).

However, we can probably do better if instead of having the general get/put interface, we have it based on the type (i8, i16, i32, ....). This will minimize the possible inlined generated code for access routines (at least for the SMP runtime and on node accesses for p4/libfabric).

So, instead of:

upcr_llvm_getn ()

we would have

upcr_llvm_get_i8()
upcr_llvm_get_i16()
upcr_llvm_get_i32()
upcr_llvm_get_i64()
upcr_llvm_get_i128()
...

merge of 3.8 broke configure (unresolved conflicts)

It appears that configure at 7e63d1b contains unresolved merge conflicts:

$ git grep -e '^<<<<<<' -e '^>>>>>>'
configure:<<<<<<< HEAD
configure:>>>>>>> merge_38
configure:<<<<<<< HEAD
configure:>>>>>>> merge_38
configure:<<<<<<< HEAD
configure:>>>>>>> merge_38

As a result, when using configure rather than cmake, I see

configure: line 6088: syntax error at line 6093: `<<' unexpected

-Paul

Solaris: wrong gcc install selected

Clang uses gcc's installation to find ctrbegin.o and crtend.o.
With my builds on Solaris, however, something is going wrong with the logic that should be finding the gcc install, and so executables cannot link:

$ /export/home/phargrov/upcnightly-64/llvm-upc/bin/clang hello.c -v 2>&1 | cat -n
     1  clang version 3.8.0  (UPC 3.8.1-0 20160504) 
     2  Target: x86_64-pc-solaris2.11
     3  Thread model: posix
     4  InstalledDir: /export/home/phargrov/upcnightly-64/llvm-upc/bin
     5  Found candidate GCC installation: /usr/gcc/4.5
     6  Found candidate GCC installation: /usr/gcc/4.8
     7  Selected GCC installation: /usr/gcc/4.5/lib/gcc/sparc-sun-solaris2.11
     8   "/export/home/phargrov/upcnightly-64/llvm-upc/bin/clang" -cc1 -triple x86_64-pc-solaris2.11 -emit-obj -mrelax-all -disable-free -main-file-name hello.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.23.1 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /export/home/phargrov/upcnightly-64/llvm-upc/bin/../lib/clang/3.8.0 -fdebug-compilation-dir /export/home/phargrov -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fobjc-runtime=gcc -fdiagnostics-show-option -o /var/tmp/hello-ba780b.o -x c hello.c
     9  clang -cc1 version 3.8.0 based upon LLVM 3.8.0 default target x86_64-pc-solaris2.11
    10  ignoring nonexistent directory "/usr/local/include"
    11  #include "..." search starts here:
    12  #include <...> search starts here:
    13   /export/home/phargrov/upcnightly-64/llvm-upc/bin/../lib/clang/3.8.0/include
    14   /usr/include
    15  End of search list.
    16   "/usr/bin/ld" -C -e _start -Bdynamic --dynamic-linker /usr/lib/amd64/ld.so.1 -o a.out /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o crtbegin.o -L/export/home/phargrov/upcnightly-64/llvm-upc/bin -L/export/home/phargrov/upcnightly-64/llvm-upc/bin/../lib -L/usr/lib/amd64/ /var/tmp/hello-ba780b.o -lgcc_s -lc -lgcc -lm crtend.o /usr/lib/amd64/crtn.o
    17  ld: fatal: file crtbegin.o: open failed: No such file or directory
    18  ld: fatal: library -lgcc: not found
    19  ld: fatal: file crtend.o: open failed: No such file or directory
    20  clang: error: linker command failed with exit code 1 (use -v to see invocation)

Notice that line 2 has correctly identified the target, and lines 5 and 6 correctly locate candidate gcc installations.
However, line 7 shows that Clang has appended en entirely wrong target triple.
The resulting "Selected GCC Installation" does not exist.

If I create a symlink from the incorrectly selected GCC install to the proper one, then full paths are used for crt{begin,end}.o in link command and (almost) everything works.
However, this is a multilib system and so the symlink approach can only fix either the -m32 or -m64 target, not both.

This was not happening prior to the 3.8 merge, FWIW.

-Paul

Build failure (bad linker flags) on Solaris-11

My Solaris-11/x86-64 builds that were working a while ago are now failing as follows:

llvm[2]: Linking Release+Asserts executable llvm-tblgen
ld: fatal: unrecognized option '--'
ld: fatal: use the -z help option for usage information
collect2: error: ld returned 1 exit status

The message ld: fatal: use the -z help option for usage information is from the Solaris linker, /usr/bin/ld, while the -- argument is probably intended for the Gnu linker. So, this appears to be related to use of the Gnu-vs-Solaris linker. Previously I know I needed to ensure /usr/gnu/bin was in my PATH prior to /usr/bin, but that no longer appears sufficient.

There may be a way to get the right behavior via arguments to configure or cmake.
I delayed reporting this for 2 days hoping to find the magical args required, but have not yet found the time to investigate.

UPC-IR: struct pointer representation

I took a look at this and created an example code:

shared int aint;
int main ()
{
  aint = 2;
}

and IR looks like this (-O0 -S -emit-llvm)

define i32 @upc_main() #0 {                                                     
entry: 
store i32 2, i32 addrspace(16)* inttoptr (i64 shl (i64 ptrtoint (i32* @aint to i64), i64 20) to i32 addrspace(16)*), align 4
ret i32 0
}

I don't know at what point this IR is being printed, but I don't see any OR instruction for thread and address. In packed version I can clearly see the OR instruction.

Based on running tests I can see that test failes from time to time as barrier is failing (it has some shared stores and atomic operations).

UPC-IR: runtime interface

At the moment an interface to the runtime is in the form of a general get/put procedures. For example:

upcr_llvm_getn (upc_remote_ptr_t src, void *dest, size_t n)

Note that we are passing remote pointer (RP) to the runtime. This will require the runtime to understand the RP composition (number of bits for thread/address). And we will end up with various macros for RP pointer manipulation, very similar to already existing macros for UPC pointer manipulation (as at the moment we have the interface optional).

It might be better option for us to use the interface where the runtime does not need to know about the RP. Something like this:

upcr_llvm_getn (int sthread, void *saddr, void *dest, size_t n)

cmake-specific build failure on Solaris

I am able to build on Solaris-11.3/amd64 only if I use configure instead of cmake (and if I disable building the unittests as mentioned in #17).

The problem seen when using cmake is that linking shared library libLTO.so is failing with a large number of undefined symbols in the std:: namespace.

When using configure, the (successful) link of this library is performed as follows:

llvm[2]: Linking Release+Asserts Shared Library libLTO.so
g++ -m32  -O3 -Wl,-R -Wl,'$ORIGIN' -rdynamic -L/export/home/phargrov/upcnightly-32/llvm-upc/bld/Release+Asserts/lib -L/export/home/phargrov/upcnightly-32/llvm-upc/bld/Release+Asserts/lib    -shared -o /export/home/phargrov/upcnightly-32/llvm-upc/bld/Release+Asserts/lib/libLTO.so /export/home/phargrov/upcnightly-32/llvm-upc/bld/tools/lto/Release+Asserts/LTODisassembler.o /export/home/phargrov/upcnightly-32/llvm-upc/bld/tools/lto/Release+Asserts/lto.o \
   -lLLVMLTO -lLLVMObjCARCOpts -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMInstrumentation -lLLVMProfileData -lLLVMTransformUtils -lLLVMBitWriter -lLLVMAnalysis -lLLVMX86Desc -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMMC -lLLVMX86Utils -lLLVMCore -lLLVMSupport -lz -lpthread -lmalloc -ledit -lncurses -lm

However, when using cmake the same link is attempted using gcc (which explains why the standard C++ library is missing):

Linking CXX shared library ../../lib/libLTO.so
cd /export/home/phargrov/upcnightly-32/llvm-upc/bld/tools/lto && /shared/cmake-2.8.12.2/bin/cmake -E cmake_link_script CMakeFiles/LTO.dir/link.txt --verbose=1
/usr/bin/gcc  -fPIC   -Wl,-M,/export/home/phargrov/upcnightly-32/llvm-upc/bld/tools/lto/LTO.exports   -Wl,-z,defs -shared  -Wl,-hlibLTO.so -o ../../lib/libLTO.so CMakeFiles/LTO.dir/LTODisassembler.cpp.o CMakeFiles/LTO.dir/lto.cpp.o ../../lib/libLLVMX86CodeGen.a ../../lib/libLLVMX86AsmPrinter.a ../../lib/libLLVMX86AsmParser.a ../../lib/libLLVMX86Desc.a ../../lib/libLLVMX86Info.a ../../lib/libLLVMX86Disassembler.a ../../lib/libLLVMCore.a ../../lib/libLLVMLTO.a ../../lib/libLLVMMC.a ../../lib/libLLVMMCDisassembler.a ../../lib/libLLVMSupport.a ../../lib/libLLVMTarget.a ../../lib/libLLVMAsmPrinter.a ../../lib/libLLVMSelectionDAG.a ../../lib/libLLVMX86AsmPrinter.a ../../lib/libLLVMX86Utils.a ../../lib/libLLVMX86Info.a ../../lib/libLLVMCodeGen.a ../../lib/libLLVMTarget.a ../../lib/libLLVMInstrumentation.a ../../lib/libLLVMBitWriter.a ../../lib/libLLVMObjCARCOpts.a ../../lib/libLLVMipo.a ../../lib/libLLVMLinker.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMInstCombine.a ../../lib/libLLVMIRReader.a ../../lib/libLLVMAsmParser.a ../../lib/libLLVMProfileData.a ../../lib/libLLVMObject.a ../../lib/libLLVMMCParser.a ../../lib/libLLVMMC.a ../../lib/libLLVMBitReader.a ../../lib/libLLVMVectorize.a ../../lib/libLLVMTransformUtils.a ../../lib/libLLVMAnalysis.a ../../lib/libLLVMCore.a ../../lib/libLLVMSupport.a -lrt -ldl -lcurses -lpthread -lz -lm -Wl,-R"\$ORIGIN/../lib"
Undefined                       first referenced
 symbol                             in file
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::rfind(char, unsigned int) const ../../lib/libLLVMAsmPrinter.a(WinCodeViewLineTables.cpp.o)
[... many more undefined std:: symbols ...]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.