similar to: [LLVMdev] Debug info BOF

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>

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 11/1/2016 4:28 PM, Martin J. O'Riordan via llvm-dev wrote: > I do not even pretend to know much about Dwarf and the representation of debug information, but it does appear that there is little or no support for the idea that a single "instruction" can correspond to multiple diverse lines in the source file. There is. There is even a patch for LLVM:

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

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

On Oct 20, 2012, at 12:58 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Rafael, > > On 19/10/12 18:27, Rafael Espíndola wrote: >>> Don't get me wrong, I don't have any good ideas about how to do this, I'm >>> just hoping someone does. End result might allow something like: >>> >>> declare void @foo(double inreg <eax,edx>

On Nov 15, 2013, at 11:16 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Taking a really quick at the gold code it looks like it tries to keep > 8176 files open. I would suggest putting a breakpoint in > Descriptors::close_some_descriptor and checking why it is failing to > close the files. That is a lot of file descriptors to keep open. It's well above my

On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: >> >> On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> But gold has at most 2 objects loaded at any time. >> >> Are you sure about

On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > But gold has at most 2 objects loaded at any time. Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: ../../third_party/gold/gold64: fatal error: out of file descriptors and couldn't close any clang: error: linker command failed with exit code 1

Also note that this is not the kind of bug for which asan is good. If we are dereferencing an uninitialized pointer, there is a high chance that the program will SEGV w/o any tool. If we are unlucky and the garbage is accidentally equal to some valid address, asan will not catch it either. Valgrind (and work-in-progress MemorySanitizer) will catch this. --kcc On Sat, Nov 3, 2012 at 5:38 AM, Eli

> Letting the module own MDNodes may not be a win for gold since it is going > to create multiple copies of MDNodes that could be shared with Context > owning MDNodes. > > For example, with debug info type uniquing, the type nodes can be shared > across modules, but with module owning MDNodes, each module will create its > own copy of the type nodes. The advantage is that the

On Wed, Nov 13, 2013 at 7:58 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > It sounds like the linker could call lto_module_dispose() right after > > lto_codegen_add_module() to help reduce the memory footprint. That > would be > > a simple linker change. A slightly larger linker change would be to > > immediately call lto_codegen_add_module()

>>> Not sure I would go all the way to specifying registers in the IL >>> (although I liked it at some point). What I like most right now is >>> something along the lines of >>> http://llvm.org/pr12193. That makes it explicit if something is on the >>> stack or in registers and that information is correct for both the >>> caller and callee.

On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> But gold has at most 2 objects loaded at any time. > > Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: > > ../../third_party/gold/gold64: fatal

Hi Mehdi, Yes, we did see your earlier post. Efficient (de)serialization is definitely important for both exporting (a la LTO and ThinLTO) and for shipping code as IR. I expect most use cases of the latter would benefit. -—Vikram // Vikram S. Adve // Professor, Department of Computer Science // University of Illinois at Urbana-Champaign // vadve at illinois.edu<mailto:vadve at

Hi Vikram, It is a bit more that just “efficient (de)serialization” as there is some amount of tradeoff to make between “size” vs “speed” vs “flexibility” (which are all some sort of “efficient”). For instance what if we get a faster deserialization but got larger size? That might be an issue for some people who’d like to ship bitcode. Another thing is that we may get better speed/size by

Just a guess, but it might have something to do with the chrome build using thin archives. On 15 November 2013 11:30, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 15, 2013, at 11:16 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> Taking a really quick at the gold code it looks like it tries to keep >> 8176 files open. I would suggest

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

On 24 October 2014 13:13, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > lib/Target/ARM: only built if the ARM target is enabled. > lib/TargetInfo/ARM: always build. Include only info that clang wants > to use: parse fpu name, construct the datalayout. Yes! That's the final plan! So, TableGen would generate two sets of files, one public and another private. The