similar to: [LLVMdev] LLVM 1.9 Release Announcement [draft #1]

LLVM 1.9 is available now! Download it here: http://llvm.org/ releases/ or view the release here: http://llvm.org/releases/1.9/docs/ ReleaseNotes.html This is a huge new release with many improvements, new features, better codegen, faster compiles, and many bugs fixed. One telling feature is that LLVM now correctly builds itself and passes all its regression tests when self-hosted: an

Hi Everyone, I'm happy to say that LLVM has made many leaps and bounds since the last update in November. Because we are bumping the major version number with this release, we're letting the release go for twice as long as our planned release schedule (6 months instead of 3). We are currently half way through the LLVM 2.0 development cycle. So far, many important and invasive changes

A: When the types are created in different contexts. I've been running into a module validation error related to phi nodes produced by the GVN pass, where the types of the incoming values aren't the same instance of IntegerType i1. I'm not certain I've found the root cause of the problem yet, it's probably due to my handling of LLVMContext & Module life cycles, and this

Jeremy Lakeman wrote: > A: When the types are created in different contexts. > > I've been running into a module validation error related to phi nodes > produced by the GVN pass, where the types of the incoming values aren't > the same instance of IntegerType i1. > > I'm not certain I've found the root cause of the problem yet, it's > probably due to my

Hi All, Here are my notes for the LLVM 1.8 release, please send me feedback :). I'm sure I've forgotten and overlooked something, if so, please let me know! <Note: we're back to 3-month release cycle: yay!> ----- 8< ----- 8< ----- High Level Changes: *. Jim has finished enough support for DWARF debugging information that it is now enabled by default in

Hi Everyone, It is getting to be that time again. I've scoured llvm-commits and collected a list of some of the major features we've developed since the last status update (from Feb 21). Please take a look and send me (off list) additions, feedback, corrections, etc. As usual, if I missed something, it's probably because there is such a huge amount of stuff happening,

On Aug 6, 2010, at 11:47 AM, Dale Johannesen wrote: > The last bit here > > + if (LoopExitBB) { > + // It is possible that for both successors isTrivialLoopExitBlock() > + // returns different exit blocks. It means that the loop isn't trivial, > + // just quit then. > + if (LoopExitBB != LoopExitBB2) > + return false; > +

Hello, Fixed patch attached. Can anyone test it? Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr5373.patch Type: application/octet-stream Size: 5846 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100811/8c0c364b/attachment.obj> -------------- next part -------------- On Aug 6, 2010, at

Feedback below.. > <will insert overview blurb here> Big new things: llvm-gcc4, new sparc > backend, Generic vector/SSE/Altivec support, X86 Scalar SSE support, > debugging support, many target-independent codegen improvements, inline asm, > llvm.org/web-reg. > > > Core LLVM IR Improvements: > > * The LLVM IR now has full support for representing

The vector LLVA extension will not be merged into the 1.6 release branch? It will make me have to merge twice: one for 1.6 and one for vector LLVA. When do you plan to merge the vector LLVA to the main trunk, please? On 26/10/05, Chris Lattner <sabre at nondot.org> wrote: > > Hi All, > > I'm putting together the announcement for the LLVM 1.6 release. Here is > what I

Hi Everyone, Here are my notes on the LLVM 1.7 release, which will go into the final release announcement. As Tanya mentioned, it has been far too long since the last release, and there have been a lot of CVS commits since Novemeber. :) I went through them all and pulled out some of the major improvements, which I've listed below. I'm certain that I have forgotten some things, so

LLVM 2.0 is done! Download it here: http://llvm.org/releases/ or view the release notes: http://llvm.org/releases/2.0/docs/ReleaseNotes.html LLVM 2.0 is a great release in many ways. It includes a wide range of new features, new optimizations, better codegen, and new targets. We were also able to signficantly revise several core aspects of the LLVM IR and design (such as the type system

Hi All, I'm putting together the announcement for the LLVM 1.6 release. Here is what I have so far. Because so much has been done, it is very likely that I have forgotten something. If you have done something that is not on the list, please send me a private email so I can add it (also, please tell me if I've made a mistake or miscredited something)! My next project is to start

The last bit here + if (LoopExitBB) { + // It is possible that for both successors isTrivialLoopExitBlock() + // returns different exit blocks. It means that the loop isn't trivial, + // just quit then. + if (LoopExitBB != LoopExitBB2) + return false; + } else if (Val) { + // if LoopExitBB == LoopExitBB2 pick the first one (true). +

All, Please welcome Zhou Sheng <zhousheng00 at gmail.com> to the LLVM development community. Sheng is from Beijing and is a Masters student at the University there. Sheng and I will be working together on some significant changes to LLVM in the coming months. Our first task is to implement integer types without signs in LLVM. You can read Chris Lattner's notes on this change at this

LLVM 1.8 is available now! Download it here: http://llvm.org/releases/ Release notes here: http://llvm.org/releases/1.8/docs/ReleaseNotes.html This is a great new release with great new features and lots of refinements (better codegen, faster compiles, bugs fixed). One particularly nice feature of this release is that we're back to a regular 3-month release cycle, allowing users to have

Morten Ofstad wrote: } Chris Lattner wrote: } >>The four leaks are caused by the ConstantBool::True } >>and ConstantBool::False (1 for each object + 1 for the use list dummy) - } >> unfortunately they are not so easy to wrap with accessor functions } >>since they are public member variables of the ConstantBool class... If } >>only everyone used the ConstantBool::get()

Chris Lattner wrote: >>The four leaks are caused by the ConstantBool::True >>and ConstantBool::False (1 for each object + 1 for the use list dummy) - >> unfortunately they are not so easy to wrap with accessor functions >>since they are public member variables of the ConstantBool class... If >>only everyone used the ConstantBool::get() there would be no problem,

Hi, I finally took the time to track down the remaining memory leaks beside the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It turns out almost all of them came from the command line options module, so I cleaned up the patch for LeakDetector and made a new patch for CommandLine. The patches are attached to this message. That got rid of all but 4 leaks I'm getting,

On Fri, 19 Nov 2004, Morten Ofstad wrote: > I finally took the time to track down the remaining memory leaks beside > the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It > turns out almost all of them came from the command line options module, > so I cleaned up the patch for LeakDetector and made a new patch for > CommandLine. The patches are attached to this