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 surprisingly well, most transformation passes keep doing their work properly. In our particular case, we found that SimplifyCFG fails to merge to basic blocks. There is one basic block, which only contains a few phi nodes and an unconditional branch. Normally, this block would be merged into its successor (when it does not cause conflicts in the phi nodes). However, when debugging info is enabled, a stop point shows up in this block. We really need to have this block simplified away, but SimplifyCFG currently doesn't know about stop points so leaves it be. It would be simple to tell SimplifyCFG, for this particular transformation, that a near-empty basic block (which can currently only contain phi nodes and a single unconditional branch) can also contain stop points. This would simply propagate the phi nodes where needed and throw away the stop point (which really can't be propagated anywhere). If your focus is on the optimizations, this is the right way to go (this allows one to debug an optimized binary). However, the removal of the stop point does slightly degrade the debugging capabilities (this particular case mostly means you can't break just before a loop that's directly preceded by other control flow). The debugging information will not become incorrect, only incomplete. If your focus is on getting complete debugging information, you would simply not want to do this transformation, so you preserve all debugging capabilities. From this observation, I think it might be useful to have some kind of global flag that tells transformations whether it is allowed to remove debugging code in favour of optimizations. When we start making transformation passes debug-info aware, I think the need for something like this might increase. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080708/1fcddbf8/attachment.sig>
On Jul 8, 2008, at 3:33 AM, Matthijs Kooijman wrote:> From this observation, I think it might be useful to have some kind > of global > flag that tells transformations whether it is allowed to remove > debugging code > in favour of optimizations. When we start making transformation passes > debug-info aware, I think the need for something like this might > increase.I envision a three level flag that the transformation passes can use to make appropriate decision. Level 1 Preserve all debug info and ability to single step in a debugger. If the transformation pass is not able to preserve these then the pass should skip the transformation. Level 2 Preserve minimum debug info to help investigate crash reports from the field (stack traces etc). Here, it is ok if single stepping capabilities are degraded. Level 3 Feel free to destroy debug info if it gets in you way. Here, the pass should not leave misleading debug info in the stream. If the info can not be fixed as part of transformation then the info should be just removed. - Devang
On Jul 8, 2008, at 3:33 AM, Matthijs Kooijman wrote:> It would be simple to tell SimplifyCFG, for this particular > transformation, > that a near-empty basic block (which can currently only contain phi > nodes and > a single unconditional branch) can also contain stop points. This > would simply > propagate the phi nodes where needed and throw away the stop point > (which > really can't be propagated anywhere).Well, technically you can move it back up before the merging and transform it to stop and then single step machine instructions until it hits the merged point. One would just need a way to express this in the debug info and have a debugger that would do that for you. :-)
On Jul 8, 2008, at 3:33 AM, Matthijs Kooijman wrote:> 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).Cool.> 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 surprisingly well, most transformation > passes keep > doing their work properly.Ok> From this observation, I think it might be useful to have some kind > of global > flag that tells transformations whether it is allowed to remove > debugging code > in favour of optimizations. When we start making transformation passes > debug-info aware, I think the need for something like this might > increase.I think that the right answer for llvm-gcc at "-O3 -g" is (eventually) for debug info to be updated where possible but discarded when necessary as you describe. For llvm-gcc we really really want 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
Hi Chris,> > From this observation, I think it might be useful to have some kind of > > global flag that tells transformations whether it is allowed to remove > > debugging code in favour of optimizations. When we start making > > transformation passes debug-info aware, I think the need for something > > like this might increase. > > I think that the right answer for llvm-gcc at "-O3 -g" is (eventually) > for debug info to be updated where possible but discarded when > necessary as you describe. For llvm-gcc we really really want 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.You explicitely mention -O3 here, so I assume you will be wanting different behaviour at -O2 and below? For this to work, some kind of gobal is required, unless you want different passes to look at the -O commandline directly (which sounds really, really bad). Any suggestions on where to put this setting? I think making it a property of PassManager 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.txtThere, 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 ability to single step in a debugger. If the transformation pass is not able to preserve these then the pass should skip the transformation. Level 2 Preserve minimum debug info to help investigate crash reports from the field (stack traces etc). Here, it is ok if single stepping capabilities are degraded. Level 3 Feel free to destroy debug info if it gets in you way. Here, the pass should not leave misleading debug info in the stream. If the info can not be fixed as part of transformation then the info should be just removed. Are these three levels acceptable? They look so to me. I think it is important to define these levels and a setting for them now, before any work starts on making transformations preserve any debugging info. Alternatively (which I think your proposal implicitely states) passes could just assume level 3, and once we get that working properly, we can worry about the other levels. However, in a lot of cases it should be fairly trivial to support all three levels, so it would be stupid not to implement all of them at the same time. For the cases where level 3 is significantly easier, we could implement just level 3 and add TODOs for the other levels. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080721/1bbb4fcb/attachment.sig>