similar to: [LLVMdev] Thread support: desirable or not?

On May 13, 2005, at 20:30, Evan Jones wrote: > should LLVM always be capable of executing multithreaded programs? On a related note, I've updated my patch to fix the bug that I found in it, and I discussed on the mailing list last month. The details can be found in the bug: http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=418 This is definitely *not* something that should go in before 1.5

On Sat, 2005-05-14 at 13:10 -0400, Evan Jones wrote: > On May 13, 2005, at 20:30, Evan Jones wrote: > > should LLVM always be capable of executing multithreaded programs? > > On a related note, I've updated my patch to fix the bug that I found in > it, and I discussed on the mailing list last month. The details can be > found in the bug: > >

On May 19, 2005, at 19:10, Chris Lattner wrote: >> Now that 1.5 has been released, would it be possible to have some >> discussion about if linking the JIT with a thread library is the >> direction that should be taken? I don't see any alternative except >> having separate "threaded" and "unthreaded" JITs, and requiring the >> user to know

On Wed, 18 May 2005, Evan Jones wrote: > On May 14, 2005, at 13:28, Reid Spencer wrote: >>> This is definitely *not* something that should go in before 1.5 is >>> released, but I would love to see it integrated shortly after. >> Okay. > > Now that 1.5 has been released, would it be possible to have some discussion > about if linking the JIT with a thread

On May 14, 2005, at 13:28, Reid Spencer wrote: >> This is definitely *not* something that should go in before 1.5 is >> released, but I would love to see it integrated shortly after. > Okay. Now that 1.5 has been released, would it be possible to have some discussion about if linking the JIT with a thread library is the direction that should be taken? I don't see any

I ran the LLVM regression tests today (via make check) and noticed that llvm-ranlib crashes with a Bus Error on my test system (a fairly old RedHat 9 system), using the latest CVS version. I did some digging and I think I know what the problem is, and I have attached a quick and dirty patch that fixes the problem for me, but I need a suggestion about how it should be integrated properly. Here

On Nov 22, 2005, at 17:18, Reid Spencer wrote: > Your patch uses an operating system call that is not portable. All > non-portable code needs to be located in the lib/System library. Yep! I know. That is why I posted it for discussion. I'm not sure if this is the "right" way to fix the problem, or if there is a different fix that should be applied (like perhaps copying the

Evan, Your patch uses an operating system call that is not portable. All non-portable code needs to be located in the lib/System library. I'm not sure why this problem appears on an old Red Hat system. Perhaps the C++ io library is not up to snuff on that platform? What compiler are you using? Reid. Evan Jones wrote: > I ran the LLVM regression tests today (via make check) and

Evan Jones wrote: > On Nov 23, 2005, at 22:49, Jeff Cohen wrote: > >> News to me. I do it all the time. Notice the "win32" directory >> under the root :) > > > Okay, so I spoke about something that I don't really know about, since > I don't use Windows. But what was the whole "Still can't compile > backend of frontend on

On Nov 23, 2005, at 18:17, Reid Spencer wrote: >> So this comment means that I should attempt to theoretically support >> Windows, and close the current archive file before updating it? > If you use sys::Path, it is not "theoretically" supported, it is > supported. Well, except of course that it isn't currently possible to build LLVM on Windows. Hence this is a

On Nov 23, 2005, at 22:49, Jeff Cohen wrote: > News to me. I do it all the time. Notice the "win32" directory under > the root :) Okay, so I spoke about something that I don't really know about, since I don't use Windows. But what was the whole "Still can't compile backend of frontend on Windows" discussion about? My impression is that LLVM only builds

I think I may have found an illegal optimization in LLVM. The problem is that if you have an empty type LLVM optimizes it away so it produces weird results. The assembler output from llvm-gcc clearly outputs the "alloca" instructions, so some other pass is removing them. I doubt if any real program relies on this behaviour, and there is a trivial work around. However, my program ran

I am trying to generate LLVM code that references a global array. Unfortunately, while I am generating the code I do not know the final length of the array, as I add elements to it as my compiler goes along. What is the best way to do this in LLVM? Ideally, I would be able to define the GlobalVariable array and change its length later on. I would love for it to have the correct length so I

Hello, I have been thinking about efficient implementation of dynamically typed languages in my spare time. Specifically, I'm working on a toy implementation of a tiny piece of Python using LLVM as a native code generating JIT. I've run into a bit of an issue, involving how Python deals with method calls. I'm not sure how/if I can implement this in LLVM. In Python, the following

On Nov 22, 2005, at 23:59, Reid Spencer wrote: >> = {0, >> 0, 4, 0}}} >> (gdb) p archPath >> $3 = {path = {static npos = 4294967295, >> _M_dataplus = {<allocator<char>> = {<No data fields>}, >> _M_p = 0x83545f4 "temp.GNU.a5\b"}, static _S_empty_rep_storage = > What's with the "5\b" at the end? Looks

Evan Jones wrote: > On Nov 23, 2005, at 18:17, Reid Spencer wrote: > >>> So this comment means that I should attempt to theoretically support >>> Windows, and close the current archive file before updating it? >> >> If you use sys::Path, it is not "theoretically" supported, it is >> supported. > > > Well, except of course that it

Evan Jones wrote: > I am pretty certain that this has nothing to do with the C++ library, > and everything to do with the behaviour of mmap when the file that was > mmaped is modified. I actually can reproduce this behaviour with the > attached C test case. The program mmaps a file called 'data,' prints the > last byte, truncates the file, then tries to read the last

Evan Jones wrote: > On Nov 23, 2005, at 12:08, Reid Spencer wrote: > >>> However, it would be possible to use a stringstream for this. >> >> Aggg! No! Those perform horribly with anything more than a small >> amount of data. Some Archive files can be huge (e.g. not fit in memory). > > > An archive can be too big to fit in memory? That would be a BIG

On Nov 22, 2005, at 19:10, Reid Spencer wrote: > 1. What is the path name associated with TmpArchive? If its the same > as the path name associated with archPath then that's a bug, probably > introduced when Path::makeUnique is called from > Path::createTemporaryFileOnDisk which is called from line 377 of > ArchiveWriter.cpp. This does not appear to be the problem. I

Hello all, I came across<http://www.r-bloggers.com/performance-benefits-of-linking-r-to-multithreaded-math-libraries/> David Smith's new post Performance benefits of linking R to multithreaded math libraries<http://blog.revolutionanalytics.com/2010/06/performance-benefits-of-multithreaded-r.html> Which explains how (and why) REvolution distribution of R uses different BLAS math