similar to: LLVM 1.2 Release & Status update

June Status Update ------------------ Hi everyone, Since the last status update, we've had a lot of progress on various fronts. In particular, we passed the 15,000th commit to the llvm-commits list, we have some great new features and documentation, new people using LLVM, and (strangely enough) the MachineBasicBlock class seems to have received a lot of love. At this point, I'm

Hi all LLVMers! It's time for another dose of LLVM status update. Since 1.1, we've fixed 34 new LLVM bugs (including a lot of quality-of-implementation bugs), sped up the optimizer, and even implemented some new features. Here are the highlights: 1. Misha reorganized the sparc backend to be a bit more modular and cleaned up the asmwriter. 2. The JIT now lazily initializes global

Hi everyone, This Fall has been busy, busy, busy. In addition to the usual LLVM hacking, our developers have been moving all over the country, starting classes, ending internships, getting married, and traveling the world. Despite all of the non-LLVM fun we've been having, we've managed to get some work done, too. :) Here is my traditional distillation of llvm-commits: New High-Level

July Status Update ------------------ Hi everyone! This month has been a busy month of cleanups and refinements, and marks over a year of LLVM status updates :). LLVM is getting substantially smaller (in memory footprint) and faster, received a few cool new features, and has a few more fixed bugs. We are currently thinking about unleashing the LLVM 1.3 release in about 3-4 weeks from now. If

Hi LLVMers, Sorry for the delay, this status update should have been out a couple weeks ago. Things have been absolutely crazy here. :) May Status Update ----------------- Overall, since the LLVM 1.2 release, we've fixed several LLVM optimizations to produce better code (most have fallen into the "stop doing stupid things" category) and implemented some new optimizations. There

Congratulations, Chris & LLVM Team. Having read nearly all the commit notices for this release I can attest to the amount of work that's gone into this release. Unfortunately, my contributions were meagre but I look forward to doing more for the 1.3 release now that I'm settled in Seattle. I'm looking forward to finally constructing my compiler with LLVM over the coming weeks.

Congratulations, Chris & LLVM Team. Having read nearly all the commit notices for this release I can attest to the amount of work that's gone into this release. Unfortunately, my contributions were meagre but I look forward to doing more for the 1.3 release now that I'm settled in Seattle. I'm looking forward to finally constructing my compiler with LLVM over the coming weeks.

The LLVM 1.4 Release is now out! Get it here: http://llvm.cs.uiuc.edu/releases/ or read about it here: http://llvm.cs.uiuc.edu/releases/1.4/docs/ReleaseNotes.html#whatsnew This release features a huge assortment of improvements in functionality, generated code quality, and compile times. Thanks to everyone who has helped make this release the best one yet. In addition to the changes

Actually, <algorithm> is not correct. This remove is in stdio.h and io.h in VC7.1. It removes a file, not elements from a collection. The proper solution is to not use remove at all and use Path::destroy_file(). On Fri, 24 Sep 2004 08:09:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > <algorithm> works too. > > On Fri, 24 Sep 2004 10:09:21 -0500 > Alkis

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the

Ok, the last status update (http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-June/000416.html) was over 7 weeks ago, sorry about that. We've been really busy squishing bugs, improving stability, and otherwise improving the system for the release. Here are some of the major accomplishments in LLVM since the last update... 1. We finally have the go-ahead from the university to release LLVM

On Sun, 2006-04-23 at 15:09 -0500, Archie Cobbs wrote: > Reid Spencer wrote: > >> 1. What is the status of the LLVM+Java effort? > > > > Incomplete but significant progress has been made. Misha Brukman can > > tell you more. > >> Is it GCJ-specific? > > > > No, it implements its own Java compiler and bytecode translator. > > Has it been

On Sun, 28 Dec 2003, Anshu Dasgupta wrote: > CodeGen/RegAlloc/PhysRegAlloc.cpp implements a graph coloring register > allocator for the Sparc back end. It requests target machine register > information via a call to getRegInfo() which returns a class > TargetRegInfo containing the required information. For the x86 target > machine, this interface has not been implemented. Is an

On Mon, 26 Apr 2004, Finn S Andersen wrote: > Alkis Evlogimenos wrote: > > >Is there a chance you can try cvs? I would be interested to > >get a simplified test case where the allocator breaks. A lot of > >improvements went into the x86 backend since 1.2 and we currently have > >no test cases where the allocator breaks today. > I updated and recompiled and the

In case anyone's interested, I followed up in the linux-nfs mailing list: https://marc.info/?l=linux-nfs&m=156887818618861&w=2 Thanks, Alkis On 9/15/19 10:51 AM, Alkis Georgopoulos wrote: > I think I got it. > > Both nfsmount and `mount -t nfs` now default to rsize/wsize = 1 MB. > By lowering this to 32K, all issues are gone, even with the default > timeo=7. And

Hello Alkis, I am writting a global register allocator, and while I was searching the web to find useful links I found your message LLVMers: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-February/000860.html I would appreciate it if you could send me the code or tell me how to access it. Thanks, Samah

Hi LLVMers, We're actively working on finishing up the release, which has been delayed. Last week was dominated by several paper submissions which were all due at about the same time, so the release fell behind (if you're interested, the papers are available on the main page). We are currently shooting for getting the release out the door early next week. That said, we have made a lot

On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: > On May 5, Misha Brukman wrote: > > To the best of my knowledge, this has not been done and no one has > > announced their intent to work on it, so if you are interested, > > you'd be more than welcome to do so. > > My C++ knowledge is completely non-existant, but so far I've had a >

I think I got it. Both nfsmount and `mount -t nfs` now default to rsize/wsize = 1 MB. By lowering this to 32K, all issues are gone, even with the default timeo=7. And nfsroot=xxx client responsiveness is a whole lot better. I think when nfsmount was initially written, the default rsize/wsize were much lower, which matched the timeo=7. Now they cause the lags/timeouts that I reported. So

On Sat, 2005-08-27 at 11:47 -0700, Reid Spencer wrote: > Alkis Evlogimenos wrote: > > It seems that these two classes are the same... Maybe they should be > > merged into 1 class? > > > I think you're looking at something old. MutexLocker doesn't exist any more. llvm/Support/ThreadSupport.h is not generated anymore? -- Alkis