similar to: [GSoC 2016] Capture Tracking - False Positives

Hey Scott, There has been quite a lot of research on capture tracking (aka escape analysis) for Java and other dynamic languages. See e.g.: https://wiki.openjdk.java.net/display/HotSpot/EscapeAnalysis http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html http://dl.acm.org/citation.cfm?doid=320384.320386 Nuno -----Original Message----- From: Scott Egerton via

On Tue, Jun 7, 2016 at 4:02 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (+CC LLVM dev - I'd dropped it in my original reply unintentionally and > just noticed.) > > On 06/07/2016 01:35 PM, Philip Reames wrote: > >> (This was written in a rush. There may be mistakes; if so I'll try to >> correct later.) >> >> At the

Hello, Attached is the proposal that I have submitted. I would be grateful for any and all feedback provided. Many Thanks, Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: GSoc Proposal 2016 - Scott Egerton.pdf Type: application/pdf Size: 391088 bytes Desc: GSoc Proposal 2016 - Scott Egerton.pdf URL:

Hello, This is a more detailed overview of my progress than the weekly reports, which can also be found on the mailing list. Over the past two weeks I have been learning a lot more about capture tracking. From this I was able to instrument the current implementation in order to identify some of the false positives in it. I was hoping to have more definitive results by now than what I

Hi Phillip, I've been looking into the Capture Tracking Improvements and I was wondering if there was any research/documentation that you know of that I could use as background reading? Many thanks, Scott

[ + cc llvm-dev]. This came up again internally and I realized I hadn’t cc’ed llvm-dev in my original response. Anna On Dec 4, 2017, at 7:06 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Davide, On Nov 29, 2017, at 1:08 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames <listmail at philipreames.com> wrote: > There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate > with other loop passes) and eliminates trivial branches. Having a simple > pass which just strips unreachable blocks and converts conditional branches > to unconditional ones while updating appropriate analyzes

Hi Davide, > On Nov 29, 2017, at 1:08 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames > <listmail at philipreames.com> wrote: >> There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate >> with other loop passes) and eliminates trivial branches. Having a simple

Dear developers, while preparing to submit a package to CRAN, I noticed that a check for lost braces in Rd files (which is enabled in the current r-devel when checking with the '--as-cran' option) seems to return false positives. More specifically, a 'Lost braces' NOTE is issued (at least sometimes) when using the \insertRef{...}{...} command from the Rdpack package. Since

I agree. Fixed in r237748. > On May 18, 2015, at 9:39 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > BTW – graphs like the one in attachment make me think that the LNT webUI should be showing > sample points by default instead of line graphs showing the minimum execution time > per build number. -------------- next part -------------- An HTML attachment was

Hi, Just for fun, I decided to run the svn r159506 llvm/clang/c++-analyzer on svn r159506 llvm-clang. I just thought that it might be interesting to run the analyzer on the llvm-clang codebase itself. I guess that most people on this list will probably have at least some knowledge of the llvm codebase, and be able to determine any false positives relatively easily ?. And for the truly

False Positives I just discovered how easy it was to create a false positive when I, trying my first RSpec test, did this: ob.should eql?(''foo'') instead of: ob.should eql(''foo'') or: ob.should == ''foo'' As far as I can see, this is roughly equivalent to: ob.should false Neither eql?(''foo'') nor false causes the spec

TL;DR: I'm looking to have AliasAnalysis passes have the ability keep a temporary cache when no transformations are performed. I'm interested to first and foremost clarify what is the best way to even start such an infrastructure change, such that it is not abused (or even available) by other passes. We certainly don't want to keep arbitrary caches in all passes. Would making this a

I agree. I think there are a lot of exciting uses for this tool. A stage 3 build bot would be another one. > On May 28, 2015, at 10:14 AM, Philip Reames <listmail at philipreames.com> wrote: > > I'd love to see this tool contributed, even it isn't used for regression detection work. I've got a couple of hacked up scripts which do similar things and having a robust

Hi, On 08/07/2015 10:30 PM, Nick Lewycky wrote: [...] > Depends. What is the exact declaration of format_long? > > > In the input .ll file it is: > > ; Function Attrs: minsize optsize > define internal i16 @format_long(i16* %res.8.par, i16 %base.9.par, > i32 %x.10.par) #3 { > > which is later changed somewhere in opt to: > > ;

Where is the best place to keep this? - As third party tool we all use? - Contribute as new project? - Lives in test-suite/utils? - Lives in llvm/utils? > On May 28, 2015, at 11:22 AM, Smith, Kevin B <kevin.b.smith at intel.com> wrote: > > OK, there is interest from at least a couple of people. What should next steps be? > > Kevin > > From: Chris Matthews

Intel has a binary comparator tool that we have been using for several years for comparing output binaries to see if the code within them is considered identical. We use it to eliminate runs (and therefore some performance noise) from our own performance tracking tools. We are willing to contribute the source code for this to the LLVM community if there is interest. There are two programs

I'd love to see this tool contributed, even it isn't used for regression detection work. I've got a couple of hacked up scripts which do similar things and having a robust tool available for this would be very useful. Philip On 05/26/2015 09:53 AM, Smith, Kevin B wrote: > > Intel has a binary comparator tool that we have been using for several > years for comparing

On Thu, May 21, 2015 at 11:24 AM, Chris Matthews <chris.matthews at apple.com> wrote: > I agree this is a great idea. I think it needs to be fleshed out a little > though. > > It would still be wise to run the regression detection algorithm, because > the test suite changes and the machines change, and the algorithm is not > perfect yet. It would be a valuable source of

On 20 May 2015 at 23:31, Sean Silva <chisophugis at gmail.com> wrote: > In the last 10,000 revisions of LLVM+Clang, only 10 revisions actually > caused the binary of MultiSource/Benchmarks/BitBench/five11 to change. So if > just store a hash of the binary in the database, we should be able to pool > all samples we have collected while the binary is the the same as it >