search for: tcaciuc

On 1/18/2013 11:11 AM, Dimitri Tcaciuc wrote: > > Right, I see. Is there any other way to solve this? As the last resort, > I was considering silently transforming each Array argument into > separate data and metadata arguments, but that would certainly add other > complications I'd rather avoid. Depends on what info...

...d 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 at anl.gov> wrote: > ----- Original Message ----- > > From: "Dimitri Tcaciuc" <dtcaciuc at gmail.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Sunday, January 27, 2013 3:42:42 AM > > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > > > > > > > Hi everyone, > > > > > > I was looking at loop vectorizer...

On Fri, Jan 18, 2013 at 6:36 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Since both "d->data" and "out->data" are both of type double, the > type-based alias analysis won't help. Right, I see. Is there any other way to solve this? As the last resort, I was considering silently transforming each Array argument into separate data and

Hi everyone, I was looking at loop vectorizer code and wondered if there was any current or planned effort to introduce SIMD implementations of sin/cos/exp/log intrinsics (in particular for x86-64 backend)? Cheers, Dimitri. -------------- next part -------------- An HTML attachment was scrubbed... URL:

----- Original Message ----- > From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> > To: "Dimitri Tcaciuc" <dtcaciuc at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, January 18, 2013 11:22:26 AM > Subject: Re: [LLVMdev] Loads not hoisted out of the loop > > On 1/18/2013 11:11 AM, Dimitri Tcaciuc wrote: > > > > Right, I see. Is there any other way to solv...

On 1/17/2013 11:33 PM, Owen Anderson wrote: > > Almost certainly, the compiler can't tell that the load from the struct > (to get the array pointer) doesn't alias with the stores to the array > itself. This is exactly the kind of thing that type-based alias > analysis (-fstrict-aliasing) can help with. Use with caution, as it > can break some type-unsafe idioms. The

----- Original Message ----- > From: "Dimitri Tcaciuc" <dtcaciuc at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Sunday, January 27, 2013 3:42:42 AM > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > > > Hi everyone, > > > I was looking at loop vectorizer code and wondered if there was any > curr...

Dimitri Tcaciuc wrote: > Is the llc/opt difference expected? Yes. "opt" runs the optimizers, which take LLVM IR as input and produce LLVM IR as output. "opt -O2 -debug-pass=Arguments" will show you a list of the individual optimizations (and analyses) that opt -O2 performs. It's poss...

On Jan 17, 2013, at 9:27 PM, Dimitri Tcaciuc <dtcaciuc at gmail.com> wrote: > Hey everyone, > > I'm looking at the following two C functions: > > http://pastebin.com/mYWCj6d8 > > Second one is about 50% slower than the first one because in the second case d->data[i * 3 + {X, Y, Z}] loads are not moved...

...t; 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 at anl.gov> wrote: > >> ----- Original Message ----- >> > From: "Dimitri Tcaciuc" <dtcaciuc at gmail.com> >> > To: llvmdev at cs.uiuc.edu >> > Sent: Sunday, January 27, 2013 3:42:42 AM >> > Subject: [LLVMdev] SIMD trigonometry/logarithms? >> > >> > >> > >> > Hi everyone, >> > >> > >&g...

Hey everyone, I'm looking at the following two C functions: http://pastebin.com/mYWCj6d8 Second one is about 50% slower than the first one because in the second case d->data[i * 3 + {X, Y, Z}] loads are not moved out of the second loop and are computed every time j increments, even though they don't depend on it. If I move those out manually, the performance of the two is equal.

Hey everyone, I'm running stock LLVM 3.1 release. Both llc and opt programs have the -O# arguments, however it looks like the results are somewhat different. Here's a silly unoptimized bit of code which I'm generating from my LLVM-backed program ; ModuleID = 'foo' %Coord = type { double, double, double } define double @foo(%Coord*, %Coord*) nounwind uwtable ssp { entry:

...lining. 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 at anl.gov > > wrote: > > > > > ----- Original Message ----- > > From: "Dimitri Tcaciuc" < dtcaciuc at gmail.com > > > To: llvmdev at cs.uiuc.edu > > Sent: Sunday, January 27, 2013 3:42:42 AM > > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > > > > > > > Hi everyone, > > > > > > I was looking at loop vec...

...in SIMD functions for multiple backends. >> >> >> >> >> >> On Sun, Jan 27, 2013 at 8:49 AM, Hal Finkel < hfinkel at anl.gov > >> wrote: >> >> >> >> >> ----- Original Message ----- >>> From: "Dimitri Tcaciuc" < dtcaciuc at gmail.com > >>> To: llvmdev at cs.uiuc.edu >>> Sent: Sunday, January 27, 2013 3:42:42 AM >>> Subject: [LLVMdev] SIMD trigonometry/logarithms? >>> >>> >>> >>> Hi everyone, >>> >>> >>...

> From: "Dimitri Tcaciuc" <[hidden email]> > Sent: Sunday, January 27, 2013 3:42:42 AM > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > I was looking at loop vectorizer code and wondered if there was any > current or planned effort to introduce SIMD implementations of > sin/cos/exp/log in...

On Fri, Jan 18, 2013 at 10:00 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > f90_array_type = type { i32 size, double* data }; I am not certain how fortran implements multi-dimensional arrays, but in my case I'm doing something like type { i32 nd, i32* dims, double* data }; Perhaps we could add !tbaa.pointer? !1 = metadata !{ metadata !"int",

FWIW, llvmpipe has C-binding code that generates (inlines) log/exp/pow/sin/cos functions of the fly, for an arbitrary number of elements (in most cases), and uses sse/avx intrinsics as available: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/gallivm/lp_bld_arit.c The precision is 20bits, which is enough for 3D. But it wouldn't be difficult to have more (or even variable)

...in SIMD functions for multiple backends. >> >> >> >> >> >> On Sun, Jan 27, 2013 at 8:49 AM, Hal Finkel < hfinkel at anl.gov > >> wrote: >> >> >> >> >> ----- Original Message ----- >>> From: "Dimitri Tcaciuc" < dtcaciuc at gmail.com > >>> To: llvmdev at cs.uiuc.edu >>> Sent: Sunday, January 27, 2013 3:42:42 AM >>> Subject: [LLVMdev] SIMD trigonometry/logarithms? >>> >>> >>> >>> Hi everyone, >>> >>> >>...

On 1/18/2013 11:34 AM, Hal Finkel wrote: > > I agree. FWIW, I'm currently working on making the LLVM-based Fortran compiler non-hypothetical, and so for several reasons, I'd like to have a solution to this. If we can't think of anything better, we could always fall back to the N^2 metadata solution (explicit mark as no-alias all pairs that don't alias), but I'd rather we

Hello everyone, For the context of question, I have a small loop written in a custom front-end which can be fairly accurately expressed with the following C program: struct Array { double * data; long n; }; #define X 0 #define Y 1 #define Z 2 void f(struct Array * restrict d, struct Array * restrict out, const long n) { for (long i = 0;