similar to: [LLVMdev] GSoC 2013

Hi Anton, I think it would be worth to remove this signature in the bottom line: Last modified: $Date: 2009/12/16 09:03:23 $ Otherwise, new people may think this page is long time abandoned :) Also, a question: may side projects that use LLVM enlist the mutually-beneficial tasks and add new categories? For example, we are interested specifically in Polly & GPU backend, plus some minor core

I'd like to see some ideas around improving the Microsoft ABI backend. There are a lot of open bugs / work-in-progress patches in the tracker so it would be nice to have someone fixing or bugs or cleaning the patches, adding tests and sending them for review. On Wed, Feb 27, 2013 at 9:32 PM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Hi Anton, > > I think it would be

Hi Dima > Also, a question: may side projects that use LLVM enlist the > mutually-beneficial tasks and add new categories? For example, we are > interested specifically in Polly & GPU backend, plus some minor core > infrastructure improvements. It seems there is "TODO" page at http://polly.llvm.org/todo.html. Maybe it should contain OpenProject or something like this

On Wed, Feb 27, 2013 at 4:32 PM, Dmitry Mikushin <dmitry at kernelgen.org> wrote: > Hi Anton, > > I think it would be worth to remove this signature in the bottom line: > > Last modified: $Date: 2009/12/16 09:03:23 $ > > Otherwise, new people may think this page is long time abandoned :) It indicates that it *is* long-abandoned! We need to start actively adding to it.

> 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

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

Hi, I suggest add the id attribute for each <h2> tag in www/index.html. Thus we can refer to the "Getting it" section in the dragonegg homepage page (the only web page) by simply the given URL: http://dragonegg.llvm.org#GettingIt Regards. On Wed, Dec 19, 2012 at 6:32 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Hi Tom, > > DragonEgg depends on GCC's

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 Tom, DragonEgg depends on GCC's and LLVM's internal headers, auto-host.h is one of them. Try to add GCC and LLVM_CONFIG with your make command as described here http://dragonegg.llvm.org/ in section "Getting it". Best, - Dima. On 12/18/2012 10:24 PM, Tom Roeder wrote: > Hi, > > I'm trying to compile release 3.2 of DragonEgg (checked out from >

Hi, I'm trying to compile release 3.2 of DragonEgg (checked out from http://llvm.org/svn/llvm-project/dragonegg/branches/release_32. I'm at revision 170458), under Ubuntu (Ubuntu 12.04.1 LTS (GNU/Linux 2.6.39-gcg-20121018 x86_64)) and I get the following error. tmroeder at myubuntu:~/src/dragonegg$ make Compiling utils/TargetInfo.cpp Linking TargetInfo Compiling Aliasing.cpp

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

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

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

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

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

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 =

Dear NVPTX community, PTXAS fails to compile the ptx code generated by NVPTX. Is it an issue of backend or an issue of PTXAS or a known reasonable restriction? Thanks, - Dima. > cat test.ll ; ModuleID = '__kernelgen_main_module' target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" target triple = "ptx64-unknown-unknown" %struct.__st_parameter_dt.0.4

Hi Mingliang LIU, > I suggest add the id attribute for each <h2> tag in www/index.html. Thus we can > refer to the "Getting it" section in the dragonegg homepage page (the only web > page) by simply the given URL: > http://dragonegg.llvm.org#GettingIt this already works: http://dragonegg.llvm.org/#gettingrelease But maybe could be done better or more consistently?

Hi Justin, gentlemen, I'm afraid I have to escalate this issue at this point. Since it was discussed for the first time last summer, it was sufficient for us for a while to have lowering of math calls into intrinsics disabled at DragonEgg level, and link them against CUDA math functions at LLVM IR level. Now I can say: this is not sufficient any longer, and we need NVPTX backend to deal with

Yes, it helps a lot and we are working on it. A few questions, 1) What will be your use model of this library? Will you run optimization phases after linking with the library? If so, what are they? 2) Do you care if the names of functions differ from those in libm? For example, it would be gpusin() instead of sin(). 3) Do you need a different library for different host