Dan
2013-May-14 22:46 UTC
[LLVMdev] Keeping Clang from changing function calls to IR operations: cmpxchg
I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile for a target that I am developing. There is an example: AtomicOps, that uses calls to: __sync_fetch_and_add __sync_val_compare_and_swap __sync_lock_test_and_set These get converted into llvm IR operations like: atomicrmw cmpxchg Is there any way to keep these as function calls, as they are easier to map to the target's eventual functional then having to deal with atomicrmw and cmpxchg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130514/b6871e5a/attachment.html>
JF Bastien
2013-May-14 23:39 UTC
[LLVMdev] Keeping Clang from changing function calls to IR operations: cmpxchg
I'm not sure if this will do everything that you want, but it controls at least some of these expansions at the Clang level: tools/clang/lib/Basic/Targets.cpp On Tue, May 14, 2013 at 3:46 PM, Dan <westdac at gmail.com> wrote:> > I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile > for a target that I am developing. > > There is an example: AtomicOps, that uses calls to: > > __sync_fetch_and_add > __sync_val_compare_and_swap > __sync_lock_test_and_set > > These get converted into llvm IR operations like: > > atomicrmw > cmpxchg > > Is there any way to keep these as function calls, as they are easier to > map to the target's eventual functional then having to deal with atomicrmw > and cmpxchg > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130514/addc908e/attachment.html>
Hello It looks like Ubuntu 13.04 has changed the include files directories structure Now we get the following error in many of our programs that compile fine on Ubuntu 12.04> clang++ -c -x c++ -emit-llvm > ../../libsimsoc/processors/ppc/ppc_llvm_lib.cpp -DNDEBUG > -I/home/vania/systemc-2.3.0/include -I/home/vania/tlm2.0/include/tlm > -DSC_INCLUDE_DYNAMIC_PROCESSES -I/usr/local/llvm/3.2/include -DNDEBUG > -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS > -D__STDC_LIMIT_MACROS -I../.. -I.. > -DABS_TOP_SRCDIR="\"/home/vania/simsoc/trunk/build/..\"" > -DABS_TOP_BUILDDIR="\"/home/vania/simsoc/trunk/build\"" > -DBINDIR="\"/usr/local/bin\"" -I ../libsimsoc -DNDEBUG -O3 -o > ppc_llvm_lib.bc > In file included from ../../libsimsoc/processors/ppc/ppc_llvm_lib.cpp:7: > In file included from ../../libsimsoc/bitwise_operator.hpp:11: > In file included from > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/vector:60: > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/stl_algobase.h:60:10: > fatal error: > 'bits/c++config.h' file not found > #include <bits/c++config.h> > ^ > 1 error generated.It happens systematically when including a header file from STL (in this case vector) that includes <bits/c++config.h> It may be a problem more related to Ubuntu 13, but it seems a general change in Linux architecture dependent includes. They have migrated architecture dependent files from /usr/include/c++/ to /usr/include/$ARCHITECTURE/c++ In my case ARCHITECTURE=x86_64-linux-gnu Is this something we have to definitely deal with in our configure script or we can expect a clang++ change ? --VJ