search for: kernelgener

Hi, After building out project in release mode, caught an assertion, which we have not seen before: hello_f: /tmp/rpmbuild_debug/BUILD/llvm/build/include/llvm/ADT/DenseMap.h:126: void llvm::DenseMap<KeyT, ValueT, KeyInfoT>::clear() [with KeyT = llvm::MachineBasicBlock*, ValueT = <unnamed>::BlockChain*, KeyInfoT = llvm::DenseMapInfo<llvm::MachineBasicBlock*>]: Assertion

Dear all, First of all, Merry Christmas! :) While testing a File I/O sample program, I've encountered a link failure due to missing implementation of "\01__isoc99_fscanf" function. I think this function should be named "__isoc99_fscanf" instead. Please see the program code and LLVM IR generated by DragonEgg and clang below. It shows that clang generates

Dear NVPTX community, I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with reprocase for this issue. Please, help us to fix it. Last 1,5 months we regularly encounter & workaround or fix 1-2 bugs per week in NVPTX backend. This is definitely not the amount of work we can completely serve ourselves... We would really really appreciate some collaboration. Thanks, - D.

Unfortunately, I cannot reproduce this. Based on your bugzilla comment, it does look like a mis-compile with your system compiler. Does the same issue occur if you build LLVM as static libraries? On 08/03/2012 12:24 AM, Dmitry N. Mikushin wrote: > Dear NVPTX community, > > I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with > reprocase for this issue. > >

Dear Zhang, Compiler ends up invoking cc1 (the backend) anyways. So if you would like to invoke it by hand, 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

> 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 are speaking more about practical side. And the practical side is: past 5 years CUDA claims to accelerate compute applications, and

Thanks for the info! I would be glad to hear of any issues you have encountered on this path. I tried to make sure the 3.3 release was fully compatible with the libdevice implementation 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

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 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

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() >

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 backend. Could you please elaborate on the rationale behind your point? Why the accuracy modes I suggested are not sufficient, in your opinion? - D.

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

The X86 back-end just calls into libm: // Always use a library call for pow. setOperationAction(ISD::FPOW , MVT::f32 , Expand); setOperationAction(ISD::FPOW , MVT::f64 , Expand); setOperationAction(ISD::FPOW , MVT::f80 , Expand); The issue is really that there is no standard math library for PTX. I agree that this is a pain for most users, but I

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're 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

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

I would be very hesitant to expose all math library functions as intrinsics. I believe linking with a target-specific math library is the correct approach, as it decouples the back end from the 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

Dear colleagues, I'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 =

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) that enables to convert CUDA

Dear all, I would like to propose an average technical project that might have a great use in many parts/derivatives of LLVM, including ours. Consider you have dozens of regression tests in high-level languages, reporting whether or not the recent changes in compiler are breaking some kind of loop handling (vectorization, parallelization, etc.). Consider you have a post-processing utility, which

> -----Original Message----- > From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com] > Sent: Wednesday, May 16, 2012 5:44 AM > To: LLVM-Dev > Cc: Justin Holewinski > Subject: NVPTX: __iAtomicCAS support ? > > Dear colleagues, > > I'm looking if we can replace nvopencc with LLVM NVPTX in our project. > It turns NVPTX won't work with the code nvopencc