similar to: [LLVMdev] opt -S change

On Sep 11, 2009, at 10:04 AM, Chris Lattner wrote: > Hi Dan, > > Please change all the tests you made use "opt %s -S" use "opt < %s - > S". I'm getting a ton of failures because of the moduleids include > the full path to the bc file and it matches grep lines. I fixed a > couple of them on mainline, but these are just a few of the ones >

If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November. If you have questions or comments about the post, this is a good thread to discuss them on :) -Chris

2011/10/28 Chris Lattner <clattner at apple.com> > > On Oct 27, 2011, at 5:37 PM, Michael Price wrote: > > Has there been much thought of attempting to automate this process? I > could imagine a fairly standard script that scrubbed a history for > interesting tidbits. Of course a standard methodology for labeling types of > commits would help this in the future. >

On 2010-01-03 10:33, Chris Lattner wrote: > If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: > http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html > > This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November. If you have questions or comments about

On Nov 8, 2012, at 7:09 AM, Joe Abbey <jabbey at arxan.com> wrote: >>> The problem we face is that bitcode changes, and when it does… future versions >>> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn >>> can BitcodeReader from LLVM 3.1, but LLVM 3.1 can't BitcodeReader LLVM 3.2 >>> (after r165739.) There was an

Hi all, I'm working on an AliasAnalysis pass that is loaded as a module. What I'd like to do is something like: opt -my-aa -O3 Where -O3 is whatever set of optimizations I'm using, but they all should use 'my-aa' for their results. However, what appears to happen is it uses my-aa until something invalidates those results and then goes back to basic-aa when something needs

On Jun 24, 2010, at 9:55 AM, Will Dietz wrote: > > Short of running -my-aa -gvn -my-aa -dse -my-aa -licm... etc, is there > a good way to do this? No. > > Having thought about it, it seems less surprising than it did > originally, but perhaps this should be mentioned somewhere? Probably. I added some text to docs/AliasAnalysis.html in r106776 for the issues that I ran into

2010/1/3 Török Edwin <edwintorok at gmail.com>: > On 2010-01-03 10:33, Chris Lattner wrote: >> If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: >> http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html >> >> This feature was added to LLVM by Bob Wilson, Dan Gohman and

On Mon, 11 Jun 2007, Dan Gohman wrote: > Here's a quick update on where I'm at with the pre-legalize vector changes > I'm working on. I hope to have an updated patch ready to a few days, assuming > I don't get too busy with other projects going on. Here are some of the issues > I've come across so far. Great! I'm going to reorder your email a bit to suit my

On Thu, 28 Feb 2019 08:16:05 +0000, Greg KH <gregkh at linuxfoundation.org> wrote: Hi both, > > On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > > Hello, > > > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > > even get to the

On Thu, 28 Feb 2019 08:16:05 +0000, Greg KH <gregkh at linuxfoundation.org> wrote: Hi both, > > On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > > Hello, > > > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > > even get to the

On Oct 29, 2010, at 12:20 PM, Brian West wrote: > On 10/29/10 1:26 PM, Eli Friedman wrote: >> Sure, but you know which induction variables you created; you can just >> zap the unused ones at the end of the pass, no? > This is feasible. We would have to collect more information during OSR > proper pass and add logic to cleanup at the end. > >>> FWIW I noticed

On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Joe, > >> We have a tool which reads in bitcode, processes it, and re-emits it. We use >> this tool as a flexible way to integrate our tool into the Xcode, Android NDK, >> Chromium, and Linux build process. >> >> The problem we face is that bitcode changes, and when it does…

On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote: >>>> After git, mainline will still be the most important branch for >>>> the *project*, >>>> but you will work with quite a few branches on parallel. >>>> >>>> >>>> Who's mainline? :) Be prepared to assign a super-merger, like Linus, >>>> to maintain

On Mon, Jun 11, 2007 at 03:39:40PM -0700, Chris Lattner wrote: > On Mon, 11 Jun 2007, Dan Gohman wrote: > > Also, CopyToReg and CopyFromReg lowering/legalization rely on being able to > > create vector-of-vector types. For example, an <8 x double> vector is bitcasted > > to (effectively) <4 x <2 x double>> for x86, allowing EXTRACT_ELEMENT to pull > >

On Mon, Jul 16, 2012 at 11:44:25AM -0700, Owen Anderson wrote: > Tom, > > I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official

On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote: > > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the

On Oct 25, 2011, at 9:29 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >> I'm removing old targets that no longer appear actively maintained, >> to reduce the burden for target-independent codegen maintenance. >> >> Does anyone object to the removal of the Alpha backend? > > It would be a shame to lose it. Alpha is an

Hello, Here's a quick update on where I'm at with the pre-legalize vector changes I'm working on. I hope to have an updated patch ready to a few days, assuming I don't get too busy with other projects going on. Here are some of the issues I've come across so far. Putting the table for extended ValueTypes in SelectionDAG seems quite involved. There are a lot of places that use

Sent from my iPhone On Nov 9, 2012, at 4:55 PM, "Chris Lattner" <clattner at apple.com> wrote: > On Nov 8, 2012, at 7:09 AM, Joe Abbey <jabbey at arxan.com> wrote: >>>> The problem we face is that bitcode changes, and when it does… future versions >>>> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn >>>>