search for: debuginfoimprov

...ant the non- debug related output of the compiler to be identical between "-O3" and "-O3 -g", and discarding this information is a reasonable way to do this. If you're interested in a path forward, I describe one reasonable one here: http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt -Chris

...riable values, but it is very useful to have them attribute time samples to source lines (even if inherently fuzzy). > Also preserving debug info about variable names can be useful. > > http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt See also: http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt :) >> For llvm.readcyclecounter, I think it's fine to inhibit >> optimizations. It's hard to understand what it means if it >> doesn't :-). Do you have an example where being able to >> do optimizations would be useful? >> > I don't have...

Hi all, I've been fiddling around with debug info generated by clang, with the goal of propagating line number info to our custom backend (which is not an llvm backend, but does use llvm IR as its input). I've created a small pass which strips all debug info except for stop points, which are currently the only things we're interested in. Leaving only stop points in actually works

[Moving discussion to LLVMdev] On 2008-10-31 21:55, Dan Gohman wrote: > Hi Török, > > @llvm.dbg.stoppoint actually does read and write memory, in a > sense. It's a point where a user could stop in a debugger, and > use the debugger to both read and write memory. If the optimizers > are allowed to reorder or delete memory operations, these > intrinsics will become

...r seems to make sense? This way, the different tools can decide how to expose the different settings to the user, and each transformation pass can easily access the setting. > If you're interested in a path forward, I describe one reasonable one here: > http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt There, you mainly describe a single goal: Prevent debugging info from interfering with optimizations at all. When looking at Devang's proposal for a three level debugging preservation setting, this would probably correspond to level 3. To recap: Level 1 Preserve all debug info and a...

...lysis pass that can give messages containing original source:line info). > >> Also preserving debug info about variable names can be useful. >> >> http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt >> > > See also: > http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt > > :) > > Thanks for the pointer. >>> For llvm.readcyclecounter, I think it's fine to inhibit >>> optimizations. It's hard to understand what it means if it >>> doesn't :-). Do you have an example where being able to >>> do...

...de how > to expose the different settings to the user, and each > transformation pass can > easily access the setting. No new global needed :) >> If you're interested in a path forward, I describe one reasonable >> one here: >> http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt > There, you mainly describe a single goal: Prevent debugging info from > interfering with optimizations at all. Right, the first goal is to make it so that enabling -g doesn't affect codegen in any way. I consider this to be a very important goal. > When looking at Dev...

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's DWARF debug info generation works reasonably well at -O0, but it is completely disabled at optimizati...