similar to: LLVM 1.6 Release!

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

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

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

LLVM 1.7 is available now! Download it here: http://llvm.org/releases/ Release notes here: http://llvm.org/releases/1.7/docs/ReleaseNotes.html This release is huge! It contains about twice the number of new features as any previous release, and includes some big-ticket items that people have been requesting for a long time. In particular, this release contains a completely rewritten llvm-gcc

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

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

Hi All, Here's the first draft of the release announcement for LLVM 1.9 that I'm working on. I'm sure I've forgotten and overlooked something, if so, please let me know! ----- 8< ------ 8< ----- <notes> Note: LLVM now correctly builds itself and passes all regression tests on Darwin X86 and Darwin PPC. No one has tried other targets to my knowledge. We hit

The LLVM 1.5 is out! Get it here: http://llvm.cs.uiuc.edu/releases/ or read about it here: http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew This release adds several new major features to the LLVM compiler, allows it to be used in domains where it couldn't before (e.g. for functional languages), supports new targets, generates faster code, and is much easier to port

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

They are all Alpha/PowerPC codegen related. Running /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/dg.exp ... FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/2005-07-12-TwoMallocCalls.ll: NODE: 0x8582a40: i32,ch = CopyFromReg 0x8582980:1, 0x85829c0 Abort trap (core dumped) FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/bsr.ll: NODE: 0x85823c0:

What's the difference between the pattern and the dag2dag instruction selectors? It seems that the pattern selector does not preserve the original dag but the dag2dag one does. Is this done so that scheduling/other opts can be performed more easily in the generated machine code? Thanks, -- Alkis -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Jan 31, 2017 at 7:12 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > I've been studying the global instruction selector introduced recently. One > of the properties of global instruction selectors is that they select > instructions across basic blocks such that they can get more information in > order to choose optimal patterns. >

I cannot understand what does the paragraph mean. Could anyone please elaborate it? http://llvm.cs.uiuc.edu/ChrisLLVM/docs/CodeGenerator.html#selectiondag_legalize "Instead of using a Legalize pass, we could require that every target-specific selector supports and expands every operator and type even if they are not supported and may require many instructions to implement (in fact, this is

Hi everyone, llvm is great! But there is one exception ;) llvm components are generally fast, but instruction selection is slooow. Let me explain. I am developing a toolkit for building virtual machines which can automatically generate a JIT compiler using the interpreter specification. llvm does the hard work of machine code generation. (Thanks to you all) I discovered that JIT compilation is

On Mon, 2005-09-05 at 14:45 +0800, Tzu-Chien Chiu wrote: > why there is no general dependency analysis for the "machin code"? > perhaps it's because the instruction scheduling is only implemented > for sparcv9? Most backends use the SelectionDAG infastructure to do this kind of thing. (Simplifying things a bit) Each basic block is selected to a DAG based IR. Then

On Mon, 2 Oct 2006, Roman Levenstein wrote: >>> Wouldn't it be possible and even more clean to have just one >>> description like (I use a pseudo-description here): >>> >>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >>> (i8mem|i16mem|i32mem):$src), >>> "mov{b} {$src, $dst|$dst, $src}", []>,

On Wed, Feb 15, 2006 at 02:53:05AM +0100, Jonas Gustavsson wrote: > I have been looking at the LLVM project for quite a bit but I was > wondering if there are any implication of using the project in a > commercial enviroment in terms of licensing restrictions and other > related issues, are there other people that use LLVM in a commecial > enviroment? LLVM's license is a

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