similar to: Code coverage BoF - notes and updates

Hi Dean, We didn't discuss using XRay instrumentation during the BoF but it is an interesting idea (by the way, thanks for your talk about XRay internals!). XRay provides the advantage of being able to turn profiling on and off, but I'm not sure how the resulting data could be used. The code coverage feature is highly dependent on the frontend's profile counter placement. The mapping

Hi, I'd like to add a new pass to LLVM which removes redundant profile counter updates. The goal is to speed up code coverage testing and profile generation for PGO. I'm sending this email out to describe my approach, share some early results, and gather feedback. Problem Overview ================ A profile counter is redundant if it's incremented in exactly the same basic blocks

There have been a lot of responses. I'll try to summarize the thread and respond to some of the questions/feedback. Summary ======= 1. We should teach GlobalDCE to strip out instrumented functions which the inliner cannot delete. 2. Sean suggests adding metadata to loads/stores of counters to convey that they do not alias normal program data. I'm not familiar with AA, but

> On Mar 11, 2016, at 5:28 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Fri, Mar 11, 2016 at 12:47 PM, Vedant Kumar <vsk at apple.com> wrote: > There have been a lot of responses. I'll try to summarize the thread and respond > to some of the questions/feedback. > > > Summary > ======= > > 1. We should teach GlobalDCE to

Vedant Kumar asked me to post my design thoughts concerning branch coverage at llvm-dev since there is general interest. My team at Texas Instruments is developing an embedded ARM C/C++ compiler with LLVM. I would like to enhance LLVM's code coverage capability with branch condition coverage (for C/C++), similar to GCC/GCOV support for branch coverage. This is useful for TI, and I think

I have been working for extending test coverage for years. Nowadays, I have several cross-testing (target != host). See http://bb.pgr.jp/console Each of them (test-*-linux) is doing; - Assume a preceding builder passes with warming ccache. - All compilation units will hit ccache whenever the tree is built before lit. - Almost all compilation units will hit ccache except for Host.cpp when

On Fri, Mar 11, 2016 at 7:04 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Mar 11, 2016 at 6:00 PM, Vedant Kumar <vsk at apple.com> wrote: > >> >> > On Mar 11, 2016, at 5:28 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> > >> > On Fri, Mar 11, 2016 at 12:47 PM, Vedant Kumar <vsk at

Hi Vedant, Thanks a lot for your comments! >It looks like a lot of the new infrastructure introduced here <https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27> consists of logic copied from the debugify implementation. Why is introducing a new pair of passes better than extending the ones we have? The core infrastructure needed to track

On Thu, Mar 10, 2016 at 8:33 PM, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Mar 10, 2016 at 7:21 PM, Vedant Kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I'd like to add a new pass to LLVM which removes redundant profile counter >> updates. The goal is to speed up code coverage

On Thu, Mar 10, 2016 at 10:13 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Mar 10, 2016 at 9:42 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: > >> >> >> On Thu, Mar 10, 2016 at 8:33 PM, Sean Silva via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Mar 10,

Greetings - Does anyone have plans for a Puppet BOF at LISA this year? I''ve seen some talk on the LOPSA configmgmt list about Config Mangement BOF''s, but nothing focused on Puppet. Please, Please, mom, can we have a BOF, PUHLEESE!!!! Luke - I hope you''ll be there so I can at least buy you dinner and beers/drinks for making my SA life easier with Puppet. Cheers, Jeff

On 20 August 2014 00:24, Gerolf Hoflehner <ghoflehner at apple.com> wrote: > My experience from leading BOFs at other conferences is more talk than action. So I suggest a different setup for this topic: how about having a working group meeting with participants who can commit time to work on this topic? Mine too, but in this case I have to say it wasn't at all what happened. It

All, I'm curious to know if anyone is interested in tracking performance (compile-time and/or execution-time) from a community perspective? This is a much loftier goal then just supporting build bots. If so, I'd be happy to propose a BOF at the upcoming Dev Meeting. Chad

Dear community, We are trying to setup a BoF ( Raising Next Generation of LLVM Developers, http://sched.co/8Yzs). In our academic-oriented environments the main work force is students: undergrads, grads or PhD (rarely postdocs). Often we have limited time to bring somebody up to speed and we have to it in a productive and motivating for both parties way. I believe most of you had

I am going to submit a proposal for a Xen BOF at DC18. Here is my first cut at a draft abstract: Title: Xen in Debian BoF Format: workshop with 25 min slot The Xen packages in Debian are in need of some work, including some tidying up, upstreaming of some Makefile patches, and updating to new versions. There is a large outstanding bug list. Also with the demise of Alioth and the

All, I have arranged for an LLVM BoF at SC13 in Denver: http://sc13.supercomputing.org/schedule/event_detail.php?evid=bof143 If you will be at SC13, have an interesting project based on or within LLVM, and would be willing to come to the BoF and spend 10 minutes or so giving an overview of it, please email me. I am trying to get a collection of people together to talk about vectorization and

Hi LLVM’ers! We are hosting a BoF at this year's Dev Meeting on a subject we hope will be of interest to some (many?) of you: shipping software (entirely) as LLVM IR. You can find our proposal in the meeting schedule online: https://llvmdevelopersmeetingbay2016.sched.org/event/8Yzq/shipping-software-as-llvm-ir The BoF is scheduled to last 45 minutes, which will go by very quickly! To make

Hi everyone, I'm pleased to announce version 0.6.0 of CELT, with many quality improvements. This includes better stereo coupling, better handling of transients, and better handling of highly tonal signals. In addition, packet loss robustness has been improved through the optional use of independent (intra) frames. CELT now supports a larger dynamic range, suitable for encoding 24-bit audio

Hey folks, Do we have proposals for an HPC focused BoF at EuroLLVM? I'd like to discuss the current efforts around integrating Polly, parallel IR efforts and vectoriser support in VPlan (like outer loop), as well as coordination on the next steps around Flang. -- cheers, --renato

Folks, Please note that the survey is still open! But it's almost time for the US LLVM meeting and I'd like to give everybody the ability to inspect the results before entering the BoF session tomorrow. Here is a zip file with the raw results (minus emails) of the data up until this morning, and a short presentation with a summary and my personal pick of the comments.