similar to: [LLVMdev] Status of use-diet so far (NO API CHANGES)

On Apr 24, 2008, at 9:03 AM, Gabor Greif wrote: > > As you can see, the use-diet changes actually lower the build time > of kimwitu++! (this is as of yesterday's r50182). > Parity is not only reached, but surpassed. Thanks for these numbers. Do you know how much of this increase is due to co-allocating Use arrays with their users, and how much is due to the actual shrinking of

On Apr 16, 2008, at 11:25 AM, Dan Gohman wrote: >> So, my idea is that these changes are performance neutral. I strongly agree with Dan that we need to measure performance to ensure there is no significant performance regression. >> I hope that this is interesting, but I'd like to ask anybody who is >> comfortable with performance testing to help provide some hard

On Apr 17, 4:12 am, Chris Lattner <sa... at nondot.org> wrote: > On Apr 16, 2008, at 11:25 AM, Dan Gohman wrote: > > >> So, my idea is that these changes are performance neutral. > > I strongly agree with Dan that we need to measure performance to > ensure there is no significant performance regression. Dan, Chris, finally I am in possession of hard performance data

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

Mike, Holger, thanks for the tips, but being a long-time subversion user, I already knew this all :-) The problem was that I did an SVN merge from branch to trunk, and I ended up with: ... M include/llvm/User.h A + include/llvm/OperandTraits.h M include/llvm/Instruction.h ... The little "+" after the "A" means, the file got copied unchanged, and I think this is

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

Hi All, here comes the patch for the second wave of Use class size reduction. I have included all the machinery that is needed, and it is *active*. The User* inside of Use is even sometimes NULL, but the algorithm is able to recover it. If there is a non-null User* present, then I am asserting that it equals the computed value. I did not receive feedback for the algorithmic part yet, so I

Hi Gabor, Can you provide performance data for this? I'd like to know what affect these changes have on compile time. Thanks, Dan On Apr 15, 2008, at 3:32 PM, Gabor Greif wrote: > Hi All, > > here comes the patch for the second wave of Use class size reduction. > > I have included all the machinery that is needed, and it is > *active*. The User* inside of Use is even

> Unfortunately I had to introduce a new GlobalVariable::Create > mechanism (I hoped to have nailed all in wave 1, but life is cruel). > I will submit scripts for the easy conversion of external projects > like the last time. One request is to explicity explain the new mechanism so people don't have to read the diffs or extrapolate from the conversion scripts. Please send a

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

On Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with

Suppose, we have 3 people called: Francis, Cedric and Nina. Base on what they have eaten, we want to cluster people by "diet", "non-diet". # original data file, named as filename "food.csv". Francis|potato Francis|chocolate Francis|chocolate Francis|milk Cedric|vegetable Cedric|vegetable Cedric|potato Nina|potato Nina|chocolate Nina|chocolate Nina|potato # Step 1: I

Hi all, can anybody confirm that llvm-gcc is broken? After following all the instructions, make gets stuck while: ggreif$ gmake gmake \ CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common " \ CONFIG_H="config.h auto-host.h

On Nov 22, 2009, at 2:08 PM, Pekka Jääskeläinen wrote: > Hi, > > Chris Lattner wrote: >> This is fine to me in principle, but please make sure this doesn't >> impact compile time or memory usage of llc somehow. > > OK. Any recommended way to do this? Is there some nice way to benchmark > speed + memory consumption of llc in LLVM testing infra at the > moment

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

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 Mon, 21 Apr 2008, Gabor Greif wrote: > Hi all, > > can anybody confirm that llvm-gcc is broken? It builds for me on x86, darwin8 (svn rev: 50048). What are you using to configure it? Whenever I have had problems building llvm-gcc, I usually have to delete my install and obj dir, make clean llvm, and start over from the top. Its a pain, but it works usually. -Tanya > >

On Fri, 4 Apr 2008, heisenbug wrote: >> point taken. thanks! > > > Whatever I try I get something like this: > > ggreif$ cd MultiSource/ > ggreif$ make > make[2]: *** No rule to make target `Output/be.bc', needed by `Output/ > burg.linked.rbc'. Stop. > make[1]: *** [Burg/.makeall] Error 2 > make: *** [Applications/.makeall] Error 2 This is the

On Apr 4, 8:06 pm, heisenbug <ggr... at gmail.com> wrote: > On Apr 4, 7:51 pm, Török Edwin <edwinto... at gmail.com> wrote: > > > > > heisenbug wrote: > > > On Apr 3, 10:53 pm, Gabor Greif <ga... at mac.com> wrote: > > > ... > > > >>> 3) Make sure that make check and some reasonable subset of llvm-test > > >>>

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