similar to: [LLVMdev] Patch for non standard usage of math functions

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 don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce

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

Hi, Yes SCEV is pretty limited on this aspect. This kind of code can trigger LLVM to explode in time/memory: https://llvm.org/bugs/show_bug.cgi?id=18606 <https://llvm.org/bugs/show_bug.cgi?id=18606> See also this llvm-dev thread: SCEV implementation and limitations, do we need "pow"? : http://lists.llvm.org/pipermail/llvm-dev/2014-February/070062.html CC: Sanjoy who may have an

Hi, I was looking at some bugs to play with, and I started with http://llvm.org/bugs/show_bug.cgi?id=18606 As I commented there, a loop is unrolled and exhibit this pattern: %mul.1 = mul i32 %mul, %mul %mul.2 = mul i32 %mul.1, %mul.1 .... With an unroll factor of 32, the last multiply has 2^32 terms in its SCEV expression. (I mean I expect it would have those terms if I was patient

On Wed, 7 Sep 2005, Tzu-Chien Chiu wrote: > I don't understand the following code snippet in LiveIntervalAnalysis.cpp. > > Why changing the type of the opreand from a virtual register to a > machine register? The register number (reg) is still a virtual > register index (>1024). This code isn't actually replacing the virtual register with a physreg. As you noticed, it

On Wed, 2005-09-07 at 15:09 +0800, Tzu-Chien Chiu wrote: > I don't understand the following code snippet in LiveIntervalAnalysis.cpp. > > Why changing the type of the opreand from a virtual register to a > machine register? The register number (reg) is still a virtual > register index (>1024). > > > bool LiveIntervals::runOnMachineFunction(MachineFunction &fn)

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.

On 2/7/14, 10:24 AM, Andrew Trick wrote: > > On Feb 5, 2014, at 12:54 AM, Mehdi Amini <mehdi.amini at silkan.com > <mailto:mehdi.amini at silkan.com>> wrote: > >> Hi, >> >> I was looking at some bugs to play with, and I started with >> http://llvm.org/bugs/show_bug.cgi?id=18606 >> >> As I commented there, a loop is unrolled and exhibit

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

On Wed, Feb 15, 2006 at 02:53:05AM +0100, Jonas Gustavsson wrote: > I have been looking at the LLVM project for quite a bit but I was > wondering if there are any implication of using the project in a > commercial enviroment in terms of licensing restrictions and other > related issues, are there other people that use LLVM in a commecial > enviroment? LLVM's license is a

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Hello! I have been looking at the LLVM project for quite a bit but I was wondering if there are any implication of using the project in a commercial enviroment in terms of licensing restrictions and other related issues, are there other people that use LLVM in a commecial enviroment? Regards Jonas Gustavsson

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

On Monday 12 October 2009 22:22, Eli Friedman wrote: > > Now I understand that llvm can have any length integer, but I consider > > turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ > > optimization. This eventually expands to a 128bit multiply call(__multi3) > > which I have absolutely no interest in supporting. So I’m wondering what > >

In addition, there are groups at STMicroelectronics and at Siemens that have used or are considering using LLVM. Note that these are internal development projects for now -- they (and Apple) have not publicly announced products based on LLVM. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Feb 14, 2006, at 11:24 PM, Misha Brukman wrote: > On Wed, Feb 15, 2006 at

Dear Olly, thanks a lot for the pointer! I've fetched the patch you mention but actually it seems this is already included in the 1.4.3 release, is that possible? Also it did not solve the problem, I still get references to exp10. I've checked with nm and omenquire.o has undefined references to log10 and exp10. I went further and replaced exp10 in omenquire.cc with __builtin_exp10, but

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