similar to: [LLVMdev] Questions about linking with math library using llvm

Hi, Since LLVM does not contain an assembler and linker to generate native code, do people have to write their own assembler if the target is different from the host? Or did I misunderstand something? Thanks. Xun Li ArchLab Department of Computer Science University of California, Santa Barbara

Hi, I was trying to use llc with soft-float option to generate soft-float code for Sparc. But it does not work. With or without -soft-float option will generate the same code for llc. Is this still an experimental feature? -- Xun Li Computer Architecture Lab Department of Computer Science University of California, Santa Barbara

On Thu, Mar 31, 2011 at 6:47 PM, John Criswell <criswell at illinois.edu> wrote: > On 3/31/11 8:39 PM, Xun Li wrote: >> >> Hi All, >> >> I am working on a custom defined architecture which implements Sparc >> ISA but without floating point instructions. >> I have two questions regarding using LLVM: >> 1. How to enable soft-float when building

Hi All, I am working on a custom defined architecture which implements Sparc ISA but without floating point instructions. I have two questions regarding using LLVM: 1. How to enable soft-float when building llvm-gcc? 2. How to let llvm-gcc generate native code (binaries) for Sparc? Do I have to compile glibc or newlib for Sparc and link with it together? I am kinda confused so it would be great

Full_Name: Emmanuel Charpentier Version: 1.2.0 OS: Linux 2.2.18 (Debian 2.2) Submission from: (NULL) (193.251.31.31) When trying "mass" installation of available packages, the package logspline does not compile, at least when installed through install.packages("logspline"). It seems that it is a small bug, such a missing #include <math.h> or -libm linking switch ?

Dan, I have a large list of functions(60+) that I want to be legalized. I have currently been adding them in the same manner as pow/exp etc... These functions come in both scalar and vector versions of up to 16 elements as the 1.0 spec requires. Is this something that I could Merge back into the tree or is another approach required? Some of the thoughts we were having as not to clutter the llvm

I've been working on some basic library call optimizations, the SimplifyLibCalls pass (lib/Transforms/IPO/SimplifyLibCalls.cpp). Tonight I conjured up a list of the potential libcall simplifications that could be done. There's a lot of them. I could use some help if anyone wants to pitch in. The individual optimizations are self-contained and fairly straight forward to write. They range

There's at least one other LLVM user which would find these useful, and probably more, so it may be appropriate to merge this into the main tree. I'm interested to hear if anyone else has an opinion here. An llvm.math namespace seems like a good idea. Instead of using "fpow" though, I'd prefer to just use names like "pow". For consistency, the ISD namespace

On Apr 8, 2009, at 12:43 AM, Duncan Sands wrote: > Hi Micah, > >> There seems to be some math library functions that are already built >> into llvm as intrinsic(pow, exp, etc...) but there are lots that >> are not >> built in yet. Is there currently work going on that is implementing >> these? I do not want to duplicate work so I want to see what is out

The lack of an open-source vector math library (which is what you suggest here) prompted me to start a project "vecmathlib", available at < https://bitbucket.org/eschnett/vecmathlib>. This library provides almost all math functions available in libm, implemented in a vectorised manner, i.e. suitable for SSE2/AVX/MIC/PTX etc. In its current state the library has rough edges, e.g.

There seems to be some math library functions that are already built into llvm as intrinsic(pow, exp, etc...) but there are lots that are not built in yet. Is there currently work going on that is implementing these? I do not want to duplicate work so I want to see what is out there. The math functions that I will be adding in are from the following spec, section 6.

Hi Micah, > There seems to be some math library functions that are already built > into llvm as intrinsic(pow, exp, etc...) but there are lots that are not > built in yet. Is there currently work going on that is implementing > these? I do not want to duplicate work so I want to see what is out > there. another approach is to get rid of the llvm intrinsics, because they don't

Hi all, I am using c++ functions in R by Rcpp and inline packages. The code is quite simple, but the R session always automatically crash after some running time. Does anyone here familiar with Rcpp and inline? What¡¯s the problem in the following code? I have checked the input values, no NA and other strange value exists. Thank you for your attention! > mkc <- cxxfunction(

Hi all, I am using c++ functions in R by Rcpp and inline packages. The code is quite simple, but the R session always automatically crash after some running time. Does anyone here familiar with Rcpp and inline? What¡¯s the problem in the following code? I have checked the input values, no NA and other strange value exists. Thank you for your attention! > mkc <- cxxfunction(

The documentation is correct, and the observation that the IR verifier is currently not verifying this property is also correct. Due to the way that dbg.declares are handled by later stages, LLVM can only keep track of one dbg.declare per variable and that is intentional. The dbg.declare intrinsic is supposed to pin a variable to a stack slot, such as in the code that clang emits at -O0. If you

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

On Apr 14, 2009, at 9:46 AM, Dan Gohman wrote: > There's at least one other LLVM user which would find these > useful, and probably more, so it may be appropriate to merge > this into the main tree. I'm interested to hear if anyone > else has an opinion here. I'd rather not see them in the main tree, since there's no real explanation of what the benefits would be

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