I try do compile my opencl kernel to llvm IR.
With the following instruction
/home/mypass/llvm/Debug+Asserts/bin/clang -I/home/ian031545/libclc/generic/include -include clc/clc.h -Dcl_clang_storage_class_specifiers -target nvptx--nvidiacl -Xclang -mlink-bitcode-file -Xclang /ian031545/libclc/nvptx--nvidiacl/lib/builtins.bc -S -emit-llvm kernel.cl -o kernel.ll
The opencl kernel's structure look like this
__kernel(){
if() x[i]=a+b+1
else x[i]=a+b+2
}
And the llvm IR after using the instruction above look like this
entry: // it perform a+b here , we say c
then part: // it perform c+1
else part: // it perform c+2
Does anyone know why does clang do this kind of optimization here ? ( we say it frontend )
Or it may not be a kind of optimization ?
I don't know why clang do this here , for what purpose ?
Can i ask clang not to do this by adding flag to the instruction above ?
Thanks in advance
Try using -O0 flag with clang.
Related
Logically I want to do something like this in my cmake build (given in pseudo C++)
exceptions_flag =
Compiler == Clang || Compiler == GCC ? "-fexceptions"
: Compiler == MSVC ? "/U_HAS_EXCEPTIONS;/D_HAS_EXCEPTIONS=1;/EHsc"
I'm not sure how to do this in one step with cmake generators the best I can think of is
set(EXCEPTIONS_FLAG
$<$<CXX_COMPILER_ID:MSVC>:"/U_HAS_EXCEPTIONS;/D_HAS_EXCEPTIONS=1;/EHsc">
if(NOT ${EXCEPTIONS_FLAG})
set(EXCEPTIONS_FLAG "-fexceptions")
endif()
Is there a better way to do this?
There are plenty of examples of using cmake to set a preprocessor value. I'm having the reverse problem -- I want to find the value of __GLIBCXX__ and then perform other cmake commands conditionally based on the result.
Up until now, I had been using the GCC version as a surrogate for libstdc++ functionality, like this:
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.6)
....
# other gcc versions
....
endif()
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
# and so on
endif()
The problem I'm now having is the fallout from a known issue with libstdc++ and gcc-4.8 c++11 regex support, and the fact on many setups clang reuses the system libstdc++, therefore inheriting the same problem. Under these circumstances, there's no version test for clang that will help, since it's specifically related to libstdc++, and my surrogate method of using the compiler version no longer works.
In order to fallback on Boost.Regex or PCRE if either clang or gcc are using the libstdc++ distributed with gcc-4.8 or earlier, the best way I can think of is to check if __GLIBCXX__ <= 20140404, but I can't see how to get cmake to do it in a straight-forward way, since clang might not always be using libstdc++, e.g. most OS X systems.
CheckVariableExists doesn't seem to help, I suppose for at least two reasons; firstly, a preprocessor macro isn't a variable, and secondly, it doesn't give the value, only indicates its presence.
You could use CHECK_CXX_SOURCE_COMPILES to compile a specific test which fails when your condition is not met:
INCLUDE (CheckCXXSourceCompiles)
CHECK_CXX_SOURCE_COMPILES(
"
#include <cstdio>
#ifdef __GLIBCXX__
#if __GLIBCXX__ <= 20140404
#error test failed
#endif
#endif
int main() { return 0;}
" GLIBCXX_TEST)
IF(NOT GLIBCXX_TEST)
MESSAGE(STATUS "__GLIBCXX__ test failed")
ENDIF()
Based on m.s.'s idea and taking Marc Glisse's observation about __GLIBCXX__ not being a reliable way to test for this, I wrote a CMake module to test for broken implementations of regex support. In order for this test to pass, the compiler will need to be targetting C++11 or higher.
Gist is here: https://gist.github.com/anonymous/7520ce6f64c63e2f8e79
Sample use:
include(CheckForRegex)
check_cxx_native_regex_works(USE_NATIVE_REGEX)
add_definitions("-DUSE_NATIVE_REGEX=${USE_NATIVE_REGEX}")
if (NOT USE_NATIVE_REGEX)
find_package(Boost REQUIRED COMPONENTS regex)
endif()
I would like to use strlcpy (to call an external api), which is missing from string.h, when I use g++'s -std=c++0x parameter.
% g++ -std=c++0x foo.cpp
foo.cpp: In function 'int main(int, char**)':
foo.cpp:5:11: error: 'strlcpy' was not declared in this scope
% g++ foo.cpp
% cat foo.cpp
#include <string.h>
int main(int argc, char* argv[])
{
const char src[] = "foo";
char dest[1024] = { 0 };
strlcpy(dest, src, sizeof(dest));
return 0;
}
Is it possible to use strlcpy and the std=c++0x flag, or do I have to drop the later?
Additionally I was not able to find the strlcpy manpage in cygwin, even though they seem to have the function. Any pointers?
I use gcc 4.7.2 on cygwin.
Quoting wikipedia: Criticism on strlcpy
The more popular strlcat and strlcpy have been criticised on the basis
that they encourage use of C strings and thus create more problems
than they solve. Consequently they have not been included in the
GNU C library (used by software on Linux), although they are
implemented in OpenBSD, FreeBSD, NetBSD, Solaris, Mac OS X, QNX, and
even internally in the Linux kernel.
When using gcc, can individual optimisation flags be enabled without a -O level being specified?
gcc -ffasst-math foo.c
OR
gcc -O1 -ffast-math foo.c
Which one works?
Thanks!
Yes, you can enable individual optimization flags.
Info from the gcc man page:
-O
-O turns on the following optimization flags:
-fauto-inc-dec -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-small-functions -fipa-pure-const -fipa-reference -fmerge-constants -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-sra -ftree-ter -funit-at-a-time
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
-ffast-math
Sets -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range.
This option causes the preprocessor macro "FAST_MATH" to be defined.
This option is not turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.
I installed the CodeSourcery g++ toolchain and tried to compile a simple hello world program:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
return 0;
}
And got a lot of errors from the linker
$ arm-none-eabi-g++ helloworld.cpp -o helloworld.exe
bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000008018
lib/libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0x10): undefined reference to `_exit'
lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0x1c): undefined reference to `_fstat'
lib/libc.a(lib_a-openr.o): In function `_open_r':
openr.c:(.text._open_r+0x20): undefined reference to `_open'
lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0x18): undefined reference to `_sbrk'
lib/libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0x1c): undefined reference to `_kill'
lib/libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x4): undefined reference to `_getpid'
lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x20): undefined reference to `_write'
lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0x18): undefined reference to `_close'
lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0x18): undefined reference to `_isatty'
lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x20): undefined reference to `_lseek'
lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x20): undefined reference to `_read'
collect2: ld returned 1 exit status
What library am I missing here?
The GCC toolchain is only half of what you need to create a working executable*. The other half is the runtime library. The runtime includes crt0.o, which contains the entry point (the code that calls main()), and generally a libc that contains the standard C functions (strcmp(), memcpy(), etc) as well as the system calls (open(), read(), and others). You need to find a source for these. If you're targeting an embedded Linux or BSD machine, you'll have to find out what libc your target is using. It's probably either GNU libc, BSD libc, newlib, or uclibc. You can get these and build them yourself, or they may be available already with your OS.
*unless you're building a freestanding binary, but this doesn't look to be what you're doing.
Basing on the cross compiler it appears that end target is bare metal. The default gcc libraries (OS dependent) will not work here. You can use the NewlibC or NewlibC-Nano. This generally will be shipped along with the cross compiler tool chain.
Look for lib folder which has precompiled NewlibC.
Once that is done,
This statement might help you to an extent.
arm-none-eabi-gcc --specs=rdimon.specs \
-Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group $(OTHER_OPTIONS)
Don't forget to provide the path of looking the libraries -L(path).
I had this same problem.
It turns out there are a handful of options you can send to the linker to make it start working, but the one that had the least splash damage in my code base was
-nostartfiles