similar to: [LLVMdev] Patch: Initialize target info for LLVM-C.

Applied as r79307, thanks On Sat, Aug 15, 2009 at 8:57 AM, José Fonseca<jose.r.fonseca at gmail.com> wrote: > Hi, > > Using a JIT engine on LLVM-C currently fails on SVN because the > LLVMInitialize???Info is never called. > > The attached patch fixes this. > > BTW, would it be possible to include a simple LLVM-C test case, like >

Does the 2.5 release version also fail for this reason? I'm trying to JIT (through LLVM-C) from code generated by my compiler, and it's segfaulting... I'd like to know if this is the problem or if something else is going wrong. On Mon, Aug 17, 2009 at 10:06 PM, Daniel Dunbar<daniel at zuster.org> wrote: > Applied as r79307, thanks > > On Sat, Aug 15, 2009 at 8:57 AM,

Attached are two patches with MSVC build enchancements. They are quite trivial, but were necessary to correctly link LLVM libraries with Mesa3D on Windows. Jose -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL:

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.

On 03/16/2011 03:39 PM, Jakob Stoklund Olesen wrote: > 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 the mailing list this time... On Sat, Mar 6, 2010 at 4:26 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 6, 2010 at 4:19 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote: >>>> --- a/include/llvm/System/DataTypes.h.cmake >>>> +++ b/include/llvm/System/DataTypes.h.cmake >>>> @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t;

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes

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

Le 06/03/2010 11:43, José Fonseca a écrit : > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. > > Jose > > Are you volontary trying to break everyone build (just to build your own project), or have you no idea of the effect of this change:

Hi, I just wanted to let you know that I committed the pointer-vector patch. Thanks, Nadav -----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

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. I think LLVM IR should support it directly. > Anyway, from

----- 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 > >> > plan. But just to

On Mar 24, 2011, at 7:23 AM, José Fonseca wrote: >>> >> I normally use 403.gcc, but if you don't have SPEC sources, these tests in the nightly test suite take a while to compile: >> >> MultiSource/Applications/ClamAV >> MultiSource/Applications/JM/ldecod >> MultiSource/Applications/JM/lencod >> MultiSource/Applications/SPASS >>

I actually had an idea about how to fix this in a relatively painless manner. Although given my experience over the past 4 days, it might not be best to call it painless without first trying :) The idea is to make a StaticPassRegistry. RegisterPass<> only touches the StaticPassRegistry, and nothing else touches the StaticPassRegistry. So once you enter main(), StaticPassRegistry can be

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

On 03/24/2011 03:30 PM, Jakob Stoklund Olesen wrote: > > On Mar 24, 2011, at 7:23 AM, José Fonseca wrote: >>>> >>> I normally use 403.gcc, but if you don't have SPEC sources, these >>> tests in the nightly test suite take a while to compile: >>> >>> MultiSource/Applications/ClamAV >>> MultiSource/Applications/JM/ldecod

On Tue, 6 Dec 2011 09:19:43 +0200 "Rotem, Nadav" <nadav.rotem at intel.com> wrote: > Hi, > > I just wanted to let you know that I committed the pointer-vector > patch. Nadav, I just committed a change to BBVectorizer to allow it to generate these (and also vector selects) [>= r154735]. If you have cases where you think these should be generated, and they're

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 do in those architectures is to specify a > 64bit scalar base pointer

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

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