debug stoppoint nodes with -fast option

I need to generate line number debug information for PIC16 target. PIC16 does not support dwarf format. It supports coff format. So I need to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT nodes are not created in dag because of the below check in SelectionDAGBuild.cpp
     if (Fast)
        DAG.setRoot(DAG.getDbgStopPoint(getRoot(),
If I give -fast option then the Fast flag is true, but the dag doesn't contain STOPPOINT nodes. If I have simple loads and stores in source code, the dag doesn't contain them too. Why are these nodes not being created?

Thanks
Vasudev

I need to generate line number debug information for PIC16 target.
PIC16 does not support dwarf format. It supports coff format. So I need
to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT
nodes are not created in dag because of the below check in
SelectionDAGBuild.cpp
    if (Fast)
       DAG.setRoot(DAG.getDbgStopPoint(getRoot(),
If I give -fast option then the Fast flag is true, but the dag doesn't
contain STOPPOINT nodes.

Right. Currently, the way we tell whether optimization was requested at the command line level is to look at -fast; -O0 == -fast.
The stoppoint nodes enforce an ordering of loads and stores corresponding to the original source, which means that putting them in without -fast would lead to codegen (scheduling) differences between -O and -O -g. We don't want that.

Instead, the debug info is transferred at this point from stoppoint nodes to the DebugLoc field in each MachineInstr node. You should probably use that.

(The current state of debug info with -O is that we think -g never affects codegen; violations of that should be reported as bugs. The quality of the debug info has not been worked on much and is problematic.)

If I have simple loads and stores in source
code, the dag doesn't contain them too. Why are these nodes not being
created?

I don't know. Something to do with your target, they appear for me.

Thanks for the info regarding DebugLoc field. Another related question that I have is regarding debug info for local variables. With -fast option, ISD::DECLARE nodes are created in DAG for debug info of local variables. I am planning to custom handle these nodes, get the required info from llvm.dbg.variable global address and emit it in ISel. But without -fast option ISD::DECLARE nodes are not created. How can i access the debug info for local variables in that case? Is it available directly somewhere in AsmPrinter like the debug info for global variables?

Dale Johannesen wrote:

Thanks for the info regarding DebugLoc field. Another related question
that I have is regarding debug info for local variables. With -fast
option, ISD::DECLARE nodes are created in DAG for debug info of local
variables. I am planning to custom handle these nodes, get the required
info from llvm.dbg.variable global address and emit it in ISel. But
without -fast option ISD::DECLARE nodes are not created. How can i
access the debug info for local variables in that case? Is it available
directly somewhere in AsmPrinter like the debug info for global variables?

Not yet. The Declare nodes interfere with optimizations, as do the Stoppoint nodes: they count as an extra Use, which affects many optimizations that are looking for a single Use (of the alloca node, or whatever). Rather than try to hunt these all down, the plan is to reimplement declarations in a way that isn't represented as a Use. This is in the early stages yet and I can't give you a date when it will work, sorry.

Can we help in local variable debug info work.

Dale Johannesen wrote:

Sure. Right now, llvm-gcc (and clang) front-end does not generate variable debug info while optimizing. On the codegen side, it is assumed that FastISel is used at -O0.

There are various independent tasks that can be tackled to improve the debug info handling by llvm tools.

- Enable llvm-gcc to emit lexical scope information, at -O0, using region.start and region.end intrinsics.

- Start using metadata to describe variable debug info in LLVM IR. The metadata helps solve "extra" use case that Dale mentioned below. Nick L. has started work to enable metadata support in mainline. See http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt for more information.

- Update LLVM IR so that each instruct optionally carry debug information.

- Update DebugLoc in the code generator to include scope information. Right now, DwarfWriter relies on the labels created during SelectionDAGBuild or FastISel to emit debug information for scopes. Eventually we want to make DwarfWriter as simple AsmPrinter feature that can collect all required info from machine instructions directly. This first step in that direction.

- At -O0, the code generate uses labels to ensure that the schedular does not re-arrange code. Find a way to overcome this and rely on DebugLoc only for the line number information.

- Improve DwarfWriter, DebugInfo and the DebugInfo interface.