similar to: [LLVMdev] LLVM BoF at SC13

Dear Michael & Hal, We had a submission to SC13 on beating OpenACC compilers with LLVM+Polly+NVPTX [1]. Unfortunately, reviewers somehow expected we want to go into polyhedral tools intercomparison, which was absolutely not our goal. The goal was exactly to bring a competitive HPC/GPU toolchain for end users. Only NV works for now, MIC is in progress. If you think this contribution is worth a

Dear community, In preparation for the BoF on Parallel IR at the US developers meeting we would like to collect feedback from the whole community. The concerns, ideas, etc. will be summarized in the BoF and should provide a good starting point for a discussion. We know that over the years the topic of a parallel extension for LLVM was discussed on the mailing list [0, 1, 2], workshops [3, 4] or

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

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

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

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

I'll happily propose one. I just usually wait for someone to bring it up. :) -eric On Aug 27, 2014 3:13 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > I haven't heard of one being proposed, but happy to chat. I wasn't sure > how much came it if last year's. > On Aug 27, 2014 7:00 AM, "Rafael Espíndola" <rafael.espindola at gmail.com>

Hi, Has anyone proposed a BOF on debug info for the next dev meeting? The one last year was quiet informative. This year the date might coincide with me trying to figure out how to make debug info processing lazier during LTO, so it would be an awesome opportunity to discuss it with developers that are more familiar with it :-) Cheers, Rafael

Hi Nadav, Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big area for fruitful work both algorithmically and in terms of practical relevance, it'd also be interesting

Hi David! On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at gmail.com> wrote: > Hi Nadav, > > Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big

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

Hello debug-info fans, There has been a lot of activity in the debug-info area lately, and I was wondering if there's interest in a BoF session this April. Alternatively we could just have a hacker-lab table again, which worked out pretty well at the last US meeting. Some potential discussion topics for the BoF/table could be: * Improving debugging of optimized code ** Defining what -Og

Debugging optimized code is a topic that generated a lot of interest at previous dev meetings, but often fell somewhat short since we've all been very busy with improving the compile-time performance impact of debug info. This year we'd like to make up for this by inviting to a dedicated session on just "-O" and "-g"! We will be giving a quick introduction to summarize

On 03/20/2018 05:05 AM, Michael Kruse wrote: > There's none yet according to http://llvm.org/devmtg/2018-04/#talks > > Unfortunately, I won't be present, but IMHO it would be nice to have one. I agree. This seems like a good idea.  -Hal > > Michael > > > > 2018-03-20 7:50 GMT+01:00 Renato Golin <renato.golin at linaro.org>: >> Hey folks, >>

Folks, Is there any interest in having a BoF session on the GCC+LLVM collaboration? I'd like to discuss some of the outcomes from the GNU Cauldron session and see what we could do to make that relationship healthier. So far, all the cross discussions I've seen on the GNU list (about LLVM) have been very healthy and the GNU folks seem very receptive to discussion (not so much for

Hi all, As you probably know, we’ll meet on the first day of the conference, right before lunch, to discuss about a possible move of our hosting to Git/GitHub, and consider the various options and associated tradeoff (Schedule entry here: http://sched.co/8Yzj <http://sched.co/8Yzj> ) I’d like to remind you that the detail of the proposals and the variants is online here:

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

Mike Edwards and I will be hosting a talk/BOF called "Living Downstream Without Drowning" which is for anyone maintaining a bunch of local changes to Clang/LLVM/etc. We will present some procedures and tactics we've evolved at Sony, including patch tactics for reducing merge pain, and how we are throwing automation at the problem. But we are really curious what YOU have done

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "David Tweed" <david.tweed at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 6, 2012 11:08:23 AM > Subject: Re: [LLVMdev] Regarding BOF: Vectorization in LLVM > > Hi David! > > On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at

Hi Martin, Yes, the patch only changes the format of line information. There will be more work needed for fully implementing it across all tools. Here your concern still stands---more focus on debug information for VLIW architectures would be welcome. I was only pointing out that the necessary capacity of the debug information to carry this data does in fact exist, and that at least one step