search for: jfonseca

This series of patches address several issues causing memory usage to grow indefinetely on a long lived process. These are not convenional leaks -- memory would have been freed when the LLVM context or/and JIT engine is destroyed -- but for as long as they aren't the memory is usage effectively ubounded. The issues were found using valgrind with '--show-reachable=yes' option: 1.

...od morning Jose, Thank you to send patches. - Please send patches to llvm-commits. - Please make patches with "--attach". You may add "format.attach" to git config. I have not seen yours yet, but I pushed yours to github; https://github.com/chapuni/LLVM/compare/ed4edf9e...jfonseca%2F20110316 (Excuse me I could not input accent) ...Takumi On Wed, Mar 16, 2011 at 8:15 AM, <jfonseca at vmware.com> wrote: > This series of patches address several issues causing memory usage to grow > indefinetely on a long lived process. > > These are not convenional leaks -...

https://bugs.freedesktop.org/show_bug.cgi?id=57737 Jos? Fonseca <jfonseca at vmware.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jfonseca at vmware.com |nouveau at lists.freedesktop.o | |rg...

Jose Fonseca <jfonseca at vmware.com> writes: > The important thing IMO, is to not represent the gather operation as > an instruction which takes a vector of pointers, because that's too > restrictive for architectures with 64bits pointers. How is it restrictive? > What one most frequently wants to...

----- Original Message ----- > Jose Fonseca <jfonseca at vmware.com> writes: > > > ----- Original Message ----- > >> "Rotem, Nadav" <nadav.rotem at intel.com> writes: > >> > >> > David, > >> > > >> > Thanks for the support! I sent a detailed email with the overall >...

Jose Fonseca <jfonseca at vmware.com> writes: > I was referring to gathering a vector of sparse 32bit words, all > relative from a base scalar pointer in a 64bit address space, where > the offsets are in a 32bit integer vector. My other reply gave a more > detailed and concrete example. Yep, I saw that....

https://bugs.freedesktop.org/show_bug.cgi?id=93454 Bug ID: 93454 Summary: Can't build with LLVM/clang 3.7.0 Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: > On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: > > > This series of patches address several issues causing memory usage to grow > > indefinetely on a long lived process. > > Thanks for working on this. > > Did you measure the performance impact of these changes? I tracked performance with this...

...e_rgba_dxt3 > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed. > > I don't really understand what these stubs are about, they were > introduced by following commit : > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > Author: Jos? Fonseca <jfonseca at vmware.com> > Date: ? Wed Apr 7 20:47:38 2010 +0100 > > ? ?util: Use stubs for the dynamically loaded S3TC functions. > > ? ?Loosely based on Luca Barbieri's commit > ? ?52e9b990a192a9329006d5f7dd2ac222effea5a5. > > Looking at llvm and r300 code and trying to guess...

On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: > This series of patches address several issues causing memory usage to grow > indefinetely on a long lived process. Thanks for working on this. Did you measure the performance impact of these changes? /jakob

greened at obbligato.org (David A. Greene) writes: > Jose Fonseca <jfonseca at vmware.com> writes: > >> The important thing IMO, is to not represent the gather operation as >> an instruction which takes a vector of pointers, because that's too >> restrictive for architectures with 64bits pointers. > > How is it restrictive? Ah, I think yo...

On Mar 16, 2011, at 6:19 AM, José Fonseca wrote: > On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: >> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: >> >>> This series of patches address several issues causing memory usage to grow >>> indefinetely on a long lived process. >> >> Thanks for working on this. >> >> Did you measure the performance impact of these changes? >...

...av -----Original Message----- From: David A. Greene [mailto:greened at obbligato.org] Sent: Tuesday, December 06, 2011 00:10 To: Jose Fonseca Cc: David A. Greene; Rotem, Nadav; LLVM Developers Mailing List Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP Jose Fonseca <jfonseca at vmware.com> writes: > I was referring to gathering a vector of sparse 32bit words, all > relative from a base scalar pointer in a 64bit address space, where > the offsets are in a 32bit integer vector. My other reply gave a more > detailed and concrete example. Yep, I saw that....

----- Original Message ----- > "Rotem, Nadav" <nadav.rotem at intel.com> writes: > > > David, > > > > Thanks for the support! I sent a detailed email with the overall > > plan. But just to reiterate, the GEP would look like this: > > > > %PV = getelementptr <4 x i32*> %base, <4 x i32> <i32 1, i32 2, i32 > > 3, i32

...ow that may indicated where the problem is: * The directory RMySQL\libs is empty---I was not expecting this. * There is a file "README.windows" in RMySQL directory which suggests some changes using the re-import utility "reimp", available at http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/software/reimp/index.html This file is missing at this location. Instead there is a note stating that it is included in MinGW distribution. I installed this, but did not find this file. * Below is the info from the installation and loading the library: > {a <- CRAN.packages() +...

...case of a base + vector-index should be easily > addressed by an intrinsic. The pointer-vector proposal comes to > support full scatter/gather instructions (such as the AVX2 gather > instructions). > > Nadav > > > -----Original Message----- > From: Jose Fonseca [mailto:jfonseca at vmware.com] > Sent: Tuesday, November 29, 2011 22:25 > To: Rotem, Nadav; David A. Greene > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and > Vector-GEP > > ----- Original Message ----- > > "Rotem, Nadav" <n...

Jose Fonseca <jfonseca at vmware.com> writes: > ----- Original Message ----- >> "Rotem, Nadav" <nadav.rotem at intel.com> writes: >> >> > David, >> > >> > Thanks for the support! I sent a detailed email with the overall >> > plan. But just to reitera...

...m: David A. Greene [mailto:greened at obbligato.org] > Sent: Tuesday, December 06, 2011 00:10 > To: Jose Fonseca > Cc: David A. Greene; Rotem, Nadav; LLVM Developers Mailing List > Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and > Vector-GEP > > Jose Fonseca <jfonseca at vmware.com> writes: > > > I was referring to gathering a vector of sparse 32bit words, all > > relative from a base scalar pointer in a 64bit address space, where > > the offsets are in a 32bit integer vector. My other reply gave a > > more detailed and concrete e...

...te nor hinder the usecase you mentioned. The case of a base + vector-index should be easily addressed by an intrinsic. The pointer-vector proposal comes to support full scatter/gather instructions (such as the AVX2 gather instructions). Nadav -----Original Message----- From: Jose Fonseca [mailto:jfonseca at vmware.com] Sent: Tuesday, November 29, 2011 22:25 To: Rotem, Nadav; David A. Greene Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP ----- Original Message ----- > "Rotem, Nadav" <nadav.rotem at intel.com> writes: &gt...

...32bit-indices. The problem is that the GEP would return a vector of pointers, which need to be reversed back to the 'base+index' form. I think that replacing the GEP/LOAD sequence with an intrinsic if probably the best choice. Nadav -----Original Message----- From: Jose Fonseca [mailto:jfonseca at vmware.com] Sent: Wednesday, November 30, 2011 18:00 To: Rotem, Nadav Cc: LLVM Developers Mailing List; David A. Greene Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP Yes, indeed I can always fallback to intrinsics. But still, I believe that the case I described is i...