search for: kernelgen

...ff785c945 in raise () from /lib64/libc.so.6 #1 0x00007ffff785df21 in abort () from /lib64/libc.so.6 #2 0x00007ffff7855810 in __assert_fail () from /lib64/libc.so.6 #3 0x00007ffff62b283d in (anonymous namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&) () from /opt/kernelgen/lib/libLLVM-3.2svn.so #4 0x00007ffff64cfb9f in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /opt/kernelgen/lib/libLLVM-3.2svn.so #5 0x00007ffff64cfc43 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /opt/kernelgen/lib/libLLVM-3.2svn.so #6 0x00007ffff64cf6e4 in l...

...lang below. It shows that clang generates "__isoc99_fscanf", while DragonEgg gives "\01__isoc99_fscanf". We generally use DragonEgg as our compiler frontend, so it is more important. What could be the reason of "\01" issue? Thanks, - Dima. marcusmae at M17xR4:~/forge/kernelgen/tests/behavior/fileio$ cat fileio.c #include <inttypes.h> #include <stdio.h> const char* filename = "fileio.txt"; int main(int argc, char* argv[]) { if (argc != 2) { printf("Test KernelGen support for File I/O\n"); printf("Usage: %s &lt...

...m /lib64/libc.so.6 > #1 0x00007ffff785df21 in abort () from /lib64/libc.so.6 > #2 0x00007ffff7855810 in __assert_fail () from /lib64/libc.so.6 > #3 0x00007ffff62b283d in (anonymous > namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&) > () from /opt/kernelgen/lib/libLLVM-3.2svn.so > #4 0x00007ffff64cfb9f in > llvm::FPPassManager::runOnFunction(llvm::Function&) () from > /opt/kernelgen/lib/libLLVM-3.2svn.so > #5 0x00007ffff64cfc43 in > llvm::FPPassManager::runOnModule(llvm::Module&) () from > /opt/kernelgen/lib/libLLVM-3.2svn....

...gt;> #1 0x00007ffff785df21 in abort () from /lib64/libc.so.6 >> #2 0x00007ffff7855810 in __assert_fail () from /lib64/libc.so.6 >> #3 0x00007ffff62b283d in (anonymous >> namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&) >> () from /opt/kernelgen/lib/libLLVM-3.2svn.so >> #4 0x00007ffff64cfb9f in >> llvm::FPPassManager::runOnFunction(llvm::Function&) () from >> /opt/kernelgen/lib/libLLVM-3.2svn.so >> #5 0x00007ffff64cfc43 in >> llvm::FPPassManager::runOnModule(llvm::Module&) () from >> /opt/kerne...

...the only thing to know is the right combination of options. Try to use the compiler verbose option "-v". It will show you how exactly clang invokes the backend: > clang -v -c showdebug.c clang version 3.2 (trunk 156703) Target: x86_64-unknown-linux-gnu Thread model: posix "/opt/kernelgen/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name showdebug.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 11 -momit-leaf-frame-pointer -...

...used to pick the proper library function in the > latter case, but I still think library function choice is better left up to > the front-end, and the accuracy attributes are a better fit to drive > optimization. > > > On Sun, Feb 17, 2013 at 9:48 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > >> Hi Justin, >> >> I don't understand, why, for instance, X86 backend handles pow >> automatically, and NVPTX should be a PITA requiring user to bring his own >> pow implementation. Even at a very general level, this limits the interest >>...

...ntation shipping with 5.5 (and as far as I know, it is). It's just not an officially supported configuration. Also, I've been meaning to address your -drvcuda issue. How would you feel about making that a part of the triple? On Wed, Jun 5, 2013 at 5:10 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Dear all, > > FWIW, I've tested libdevice.compute_20.10.bc and > libdevice.compute_30.10.bc from /cuda/nvvm/libdevice shipped with CUDA 5.5 > preview. IR is compatible with LLVM 3.4 trunk that we use. Results are > correct, performance - almost the same as wha...

...ible with LLVM 3.4 trunk that we use. Results are correct, performance - almost the same as what we had before with cicc-sniffed IR, or maybe <10% better. Will test libdevice.compute_35.10.bc once we will get K20 support. Thanks for addressing this, - D. 2013/2/17 Dmitry Mikushin <dmitry at kernelgen.org> > > The issue is really that there is no standard math library for PTX. > > Well, formally, that could very well be true. Moreover, in some parts CPU > math standard is impossible to accomplish on parallel architectures, > consider, for example errno behavior. But here we...

On Thu, Aug 2, 2012 at 8:56 AM, Xinglin Zhang <xinglinzh at gmail.com> wrote: > Hi, > > I am quite new to LLVM. I just compiled LLVM and clang on Ubuntu11.10 then > followed the tutorial http://llvm.org/docs/DebuggingJITedCode.html > > clang -cc1 -O0 -g -emit-llvm showdebug.c > > > where showdebug.c contains: > > #include<stdio.h> > int main() >

...program/language. Users should be free to use any math library > implementation they choose. Intrinsics are meant for functions that > compile down to specific isa features, like fused multiply add and square > root. > On Feb 16, 2013 8:46 PM, "Dmitry Mikushin" <dmitry at kernelgen.org> wrote: > >> Dear Yuan, >> >> Sorry for delay with reply, >> >> Answers on your questions could be different, depending on the math >> library placement in the code generation pipeline. At KernelGen, we >> currently have a user-level CUDA math mod...

Hi, I am quite new to LLVM. I just compiled LLVM and clang on Ubuntu11.10 then followed the tutorial http://llvm.org/docs/DebuggingJITedCode.html clang -cc1 -O0 -g -emit-llvm showdebug.c where showdebug.c contains: #include<stdio.h> int main() { printf("hello\n"); return 0; } But I got Fatal error: 'stdio.h' file not found. However, clang showdebug.c has no

Dear Yuan, Sorry for delay with reply, Answers on your questions could be different, depending on the math library placement in the code generation pipeline. At KernelGen, we currently have a user-level CUDA math module, adopted from cicc internals [1]. It is intended to be linked with the user LLVM IR module, right before proceeding with the final optimization and backend. Last few months we are using this method to temporary workaround the absence of many math fun...

...The accuracy modes can be used to pick the proper library function in the latter case, but I still think library function choice is better left up to the front-end, and the accuracy attributes are a better fit to drive optimization. On Sun, Feb 17, 2013 at 9:48 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Hi Justin, > > I don't understand, why, for instance, X86 backend handles pow > automatically, and NVPTX should be a PITA requiring user to bring his own > pow implementation. Even at a very general level, this limits the interest > of users to LLVM NVPTX back...

...e keeping the state locally now, perhaps we should store it in a > per-thread variable. I know rand() isn't thread safe to begin with, but it > seems like rand_r() can be since it should keep no external state. > > > On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > >> Dear all, >> >> In our LLVM-based compiler pipeline a major part of code generation is >> taken into application runtime. One side-effect of this organization is a >> need to be very careful about using code that might diverge application >>...

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> > >> If we...

...needs of the source program/language. Users should be free to use any math library implementation they choose. Intrinsics are meant for functions that compile down to specific isa features, like fused multiply add and square root. On Feb 16, 2013 8:46 PM, "Dmitry Mikushin" <dmitry at kernelgen.org> wrote: > Dear Yuan, > > Sorry for delay with reply, > > Answers on your questions could be different, depending on the math > library placement in the code generation pipeline. At KernelGen, we > currently have a user-level CUDA math module, adopted from cicc internals...

...39;m looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID = '/opt/kernelgen/include/kernelgen_monitor.cu' target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" target triple = "ptx64-unknown-unknown" %struct.kernelgen_callback_t = type { i32, i32, %"struct.kernelgen::kernel_t"*, i32,...

On Wed, Apr 8, 2015 at 10:12 AM, Dmitry Mikushin <dmitry at kernelgen.org> wrote: > A tool of this kind here: https://github.com/apc-llc/nvcc-llvm-ir > > 2015-04-08 19:01 GMT+02:00 Ahmed ElTantawy <ahmede at ece.ubc.ca>: > >> Hi, >> >> I wanted to ask whether there is ongoing effort (or an already >> established tool) tha...

...tly interested in C and Fortran), it is preferred to have GCC frontend support (maybe over plugin and emitting to debug info, rather than to GIMPLE), and then - to parse this additional info at DragonEgg level. I'm not sure what is the situation with GSoC for LLVM this year. In any case, we at KernelGen would like to support a student effort in implementing this functionality and invite other groups to co-mentor the process. Dear students, should you have any questions - please do not hesitate to contact me directly. You can also learn more about our work here [1]. [1] https://hpcforge.org/plugi...

...A-C built-in function; the implementation is provided by a library linked with the LLVM IR before the NVPTX back-end sees it. You will need to provide your own implementations for such functions. > > Thanks, > - Dima. > > SOURCE > ======== > > dmikushin at hp2:~> cat kernelgen_monitor.ll > ; ModuleID = '/opt/kernelgen/include/kernelgen_monitor.cu' > target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" > target triple = "ptx64-unknown-unknown" > > %struct.kernelgen_callback_t = type { i32, i32, > %"struct.ke...