search for: evanjones

...ans that it must always be linked against a platform's thread library. So the question is: Should the JIT always have locks, and always be thread-safe? This question really means "should LLVM always be capable of executing multithreaded programs?" Evan Jones -- Evan Jones http://evanjones.ca/

...s is fine. Does that mean option 1 or option 2 is fine: 1. Always link the JIT against a platform's thread library so it is always thread-safe. 2. Build two JITs, one that is thread-safe, and another which is not. Users must manually select the correct JIT. Evan Jones -- Evan Jones http://evanjones.ca/

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

...t is still open, but only when it was opened with delete share permission. This requires that the file be opened with the CreateFile API, which LLVM cannot do in a portable fashion. This functionality cannot be accessed via fopen. > > Evan Jones > > -- > Evan Jones > http://evanjones.ca/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >

...al, and the test was always returning true. The workaround is to put something in the structure so that LLVM doesn't optimize it away. The question is what does the C standard require? I'm assuming that GCC is doing the right thing, but I could be wrong. Evan Jones -- Evan Jones http://evanjones.ca/

...an API perspective. In fact, with regards to the specific "cannot unlink while open" issue, Cygwin works around it (partially) by removing the file as soon as the file is closed. I'm not sure that would be sufficient in this case, but it might be. Evan Jones -- Evan Jones http://evanjones.ca/

...globalArray( int index ) { return &array[index]; } Ideally, LLVM could then inline the function. Is there a better way to arrange for this to occur? Should I not care about array lengths and just have my global variable be a pointer? Thanks for the advice, Evan Jones -- Evan Jones http://evanjones.ca/

...------------ A non-text attachment was scrubbed... Name: archive.patch Type: application/octet-stream Size: 5977 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20051123/71374df4/attachment.obj> -------------- next part -------------- -- Evan Jones http://evanjones.ca/

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

...------------ A non-text attachment was scrubbed... Name: archive.patch Type: application/octet-stream Size: 1071 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20051122/e5d04595/attachment.obj> -------------- next part -------------- -- Evan Jones http://evanjones.ca/

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

...> Unix. I'm not sure how this should be solved correctly. The other > strange part is why hasn't anyone else seen this problem? I would think > that this would occur pretty reliably on all systems. Any ideas? > > Evan Jones > > > -- > Evan Jones > http://evanjones.ca/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmd...

...be moved into place. Also, since writeToDisk() invalidates the mapped file that was originally used to create the archive, shouldn't this function also unmap that file and erase all its members? This would prevent and further bugs like this from happening. Evan Jones -- Evan Jones http://evanjones.ca/

.../attachment.c> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-buserror.cpp URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20051122/fc0b2085/attachment.ksh> -------------- next part -------------- -- Evan Jones http://evanjones.ca/

...d 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 is released, but I would love to see it integrated shortly after. Evan Jones -- Evan Jones http://evanjones.ca/

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

...king 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 when the different JITs should be used. Thanks, Evan Jones -- Evan Jones http://evanjones.ca/

On Tue, 1 Nov 2005, Evan Jones wrote: > 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

...obalVariable *not* return types with internal linkage? There must be some logic behind that choice that I can't figure out. It is easy to copy the code out of Module.cpp if you need to find variables with internal linkage, but it seems unnecessary to me. Thanks, Evan -- Evan Jones http://evanjones.ca/

...ong. Should I be deleting the pointers that I get out of the module? A related question is how should I delete the module? I see that there is a "dropAllReferences" method. Is this called automatically for me from the Module's destructor? Thanks, Evan Jones -- Evan Jones http://evanjones.ca/