search for: dtcaciuc

...t 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 code and wondered...

----- 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 > current or planned effo...

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 out of the s...

...peline 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 looki...

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.

...so > 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 code and won...

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:

...or 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 a...

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

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

----- 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 solve this? As the last...

...or 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 a...

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

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

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;

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

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 information you have available. If all you have is the LLVM IR,

Hello everyone, I'm trying to tag certain load instructions with specialized metadata and make use of it in an AA pass. However, it seems that metadata is getting lost when instructions are merged together. Here's a toy problem with one intentionally duplicated load to illustrate the issue. http://susepaste.org/3af3a676 The above paste has two before/after IR pairs (the `before`

Hello everyone, Proceeding with an effort to optimize pointer-arg-to-struct-with-data-pointer arrangement, I'm taking a shot at writing a specific AA pass. I've got a scaffold up modelling after BasicAA and bumped into a few issues. Here's a snippet of IR I'm dealing with. Slice is the wrapper structure and "data" pointer is element 0 and we're looking at two of

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: