similar to: [LLVMdev] [Discussion] Portable SIMD programming using LLVM?

Hi Kevin, > *Background* > Almost modern processor families support SIMD instruction sets but the > instruction set designs for each platform have different combinations of > operations. The portable SIMD here is to make an uniform system of SIMD > operations at all power-of-2 field widths. > For example, for simd_add on SSE2, I want to have all the following operations >

Right. LLVM supports the transformation from unsupported vector type to supported vector type or even scalar types. According to the LLVM's documentation, LLVM has two ways of doing the transformation, one is promoting the small vector type to larger vector type, the other is breaking up the large vector type into smaller ones. But I am wondering, how good the transformation will be in

Hi everyone. After lurking for a while, this is my first post to the list. I am working with some graduate students on the general topic of compiler support for SIMD programming and specific projects related to LLVM and my own Parabix technology (parabix.costar.sfu.ca). Right now we have a few course projects on the go and already a question arising out of one of them (SSE2 Hoisting).

Hello all, I'm currently in the process of debugging a crash occurring in our program. In LLVM 3.2 and 3.3 it appears that JIT generated code is attempting to perform access unaligned memory with a SSE2 instruction. However this only happens under certain conditions that seem (but may not be) related to the stacks state on calling the function. Our program acts as a front-end, using the

As someone off list just told me, perhaps my new bug is the same issue: http://llvm.org/bugs/show_bug.cgi?id=16640 Do you happen to be using FastISel? Solomon On Jul 16, 2013, at 6:39 PM, Peter Newman <peter at uformia.com> wrote: > Hello all, > > I'm currently in the process of debugging a crash occurring in our program. In LLVM 3.2 and 3.3 it appears that JIT generated

Sorry, that should have been llvm.x86.sse2.sqrt.pd On 19/07/2013 3:25 PM, Craig Topper wrote: > What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things > prefixed with "llvm.x86". > > > On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <peter at uformia.com > <mailto:peter at uformia.com>> wrote: > > After stepping through the

If I generate IR using 'vector' types, for example, if my code assembles IR like this: define <4 x float> @simd_mul(<4 x float>, <4 x float>) { %3 = fmul <4 x float> %0, %1 ret <4 x float> %3 } I assume that when I JIT, it will generates the best SIMD instructions available on the host it's running on? For example, when running on a

After stepping through the produced assembly, I believe I have a culprit. One of the calls to @frep.x86.sse2.sqrt.pd is modifying the value of ECX - while the produced code is expecting it to still contain its previous value. Peter N On 19/07/2013 2:09 PM, Peter Newman wrote: > I've attached the module->dump() that our code is producing. > Unfortunately this is the smallest test

What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed with "llvm.x86". On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <peter at uformia.com> wrote: > After stepping through the produced assembly, I believe I have a culprit. > > One of the calls to @frep.x86.sse2.sqrt.pd is modifying the value of ECX - > while the produced code is

In the disassembly, I'm seeing three cases of call 76719BA1 I am assuming this is the sqrt function as this is the only function called in the LLVM IR. The code at 76719BA1 is: 76719BA1 push ebp 76719BA2 mov ebp,esp 76719BA4 sub esp,20h 76719BA7 and esp,0FFFFFFF0h 76719BAA fld st(0) 76719BAC fst dword ptr [esp+18h] 76719BB0 fistp

That should map directly to sqrtpd which can't modify ecx. On Thu, Jul 18, 2013 at 10:27 PM, Peter Newman <peter at uformia.com> wrote: > Sorry, that should have been llvm.x86.sse2.sqrt.pd > > > On 19/07/2013 3:25 PM, Craig Topper wrote: > > What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed > with "llvm.x86". >

Hi, A few questions: Is libtheora strictly backward compatible with VP3? Can I set it up to shove raw VP3 data through and trust it to decode the same way as On2's open source code did, loop filters and all? Also, is libtheora just supposed to be a C-based reference implementation? I was looking through the code and noticed a distinct lack of any kind of optimizations. Naive tree-based

I'm wondering if it makes sense to instead supply a bc math library. I would think it would be easier to maintain and debug, and should still give you all of the benefits. You could just link with it early in the optimization pipeline to ensure inlining. This may also make it easier to maintain SIMD functions for multiple backends. On Sun, Jan 27, 2013 at 8:49 AM, Hal Finkel <hfinkel

Is there something specifically required to enable SSE? If it's not detected as available (based from the target triple?) then I don't think we enable it specifically. Also it seems that it should handle converting to/from the vector types, although I can see it getting confused about needing to do that if it thinks SSE isn't available at all. On 19/07/2013 3:47 PM, Craig Topper

Hi Francesco, a bit more information. GCC veclib is implemented based on GCC VectorABI for declare simd as well. For name mangling, we have to follow certain rules of C/C++ (e.g. prefix needs to _ZVG ....). David Majnemer who is the owner and stakeholder for approval for Clang and LLVM. Also, we need to pay attention to GCC compatibility. I would suggest you look into how GCC VectorABI can

hello, i am trying to optimize omp simd loop as follows int main(int argc, char **argv) { const int size = 1000000; float a[size], b[size],c[size]; #pragma omp simd for (int i=0; i<size; ++i) { c[i]= a[i] + b[i]; } return 0; } i run it using the following command; g++ -O0 --std=c++14 -fopenmp-simd lab.cpp -Iinclude -S -o lab.s

i changed my code to following; #pragma omp simd for (int i=0; i<size; ++i) { a[i]=2; b[i]=3; c[i]=4; c[i]= a[i] + b[i]; printf("c value %f",c[i]); } still no effect of omp simd? On Sun, Dec 31, 2017 at 12:26 AM, Craig Topper <craig.topper at gmail.com> wrote: > The for loop has no effect on the observable behavior of

Hi Xinmin, I have updated the clang patch using the standard name mangling you suggested - I was not fully aware of the C++ mangling convention “_ZVG”. I am using “D” for 64-bit NEON and “Q” for 128-bit NEON, which makes NEON vector symbols look as follows: _ZVGQN2v__Z1fd _ZVGDN2v__Z1ff _ZVGQN4v__Z1ff Here “Q” means -> NEON 128-bit, “D” means -> NEON 64-bit Please notice that although

Hmm, maybe sse isn't being enabled so its falling back to emulating sqrt? On Thu, Jul 18, 2013 at 10:45 PM, Peter Newman <peter at uformia.com> wrote: > In the disassembly, I'm seeing three cases of > call 76719BA1 > > I am assuming this is the sqrt function as this is the only function > called in the LLVM IR. > > The code at 76719BA1 is: > >

I even tried following; int main(int argc, char **argv) { const int size = 1000000; float a[size], b[size],c[size]; #pragma omp simd for (int i=0; i<size; ++i) { a[i]=2; b[i]=3; c[i]=4; c[i]= a[i] + b[i]; } return 0; } but the output with and without openmp simd is same. why is that so? On Sun, Dec 31, 2017 at 12:01