Optimisation breaks debug records: region.start/region.end

[llvmbot]

Bugzilla Link	2083
Resolution	INVALID
Resolved on	Feb 28, 2008 11:59
Version	2.2
OS	Linux
Attachments	Demo sourtce file
Reporter	LLVM Bugzilla Contributor
CC	@asl

Extended Description

The test case is a C program which makes a series of calls to function check(). When compiled with no optimisation and disassembled thusly:

% llvm-gcc 20000223-1.c -g -c --emit-llvm
% llvm-dis -f 20000223-1.o

you will see that in the code for function check() there are debug intrinsic functions for a region start and end, and the region.end is correctly matched to the block (first and last lines of the code fragment):

20000223-1.o.ll (fragment):

    call void @​llvm.dbg.region.start( {  }* bitcast (%llvm.dbg.block.type* @​llvm.dbg.block to {  }*) )
    call void @​llvm.dbg.stoppoint( i32 12, i32 0, {  }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit to {  }*) )
    call void @​abort( )
    unreachable
            ; No predecessors!
    call void @​llvm.dbg.stoppoint( i32 12, i32 0, {  }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit to {  }*) )
    call void @​llvm.dbg.region.end( {  }* bitcast (%llvm.dbg.block.type* @​llvm.dbg.block to {  }*) )

If you now optimise by running opt and disassemble:

opt -f -std-compile-opts 20000223-1.o -o 20000223-1.o
llvm-dis -f 20000223-1.o

you will see that the region.end has been amended and is now incorrectly paired with a subprogram. Furthermore, this function check() is inlined into the main function and the problem is replicated in each case.

20000223-1.o.ll (fragment):

cond_true: ; preds = %entry
call void @​llvm.dbg.region.start( { }* bitcast (%llvm.dbg.block.type* @​llvm.dbg.block to { }) )
call void @​llvm.dbg.stoppoint( i32 12, i32 0, { } bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit to { }*) )
call void @​abort( )
unreachable

return: ; preds = %entry
call void @​llvm.dbg.stoppoint( i32 14, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit to { }) )
call void @​llvm.dbg.region.end( { } bitcast (%llvm.dbg.subprogram.type* @​llvm.dbg.subprogram to { }*) )

[llvmbot]

Fixing version. This was 2.2 release.

[asl]

Optimization of the code with debug information currently is not supported at all.

[llvmbot]

FWIW, this seems to be a problem in the CFGSimplificationPass. If you invoke opt with -simplifycfg rather than std-compile-opts these are the differences:

159c159
< br i1 %toBool, label %cond_true, label %cond_next

  br i1 %toBool, label %cond_true, label %return

166,172d165
< ; No predecessors!
< call void @​llvm.dbg.stoppoint( i32 12, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit to { }) )
< call void @​llvm.dbg.region.end( { } bitcast (%llvm.dbg.block.type* @​llvm.dbg.block to { }*) )
< br label %cond_next
<
< cond_next: ; preds = %0, %entry
< br label %return
174c167
< return: ; preds = %cond_next

return: ; preds = %entry
253,255d245
< br label %return
<
< return: ; preds = %entry

You'll notice that the region end for the block has been lost.

[lattner]

simplifycfg is doing the right thing, the code generator should tolerate this.

[llvmbot]

That's interesting to know. In this case the code generator is one I am working on and I'd much rather fix that than delve into the code for simplifycfg, so it's also good news! But I'm not sure what to do with this: per the docs, for every llvm.dbg.region.start intrinsic I am expecting a matching llvm.dbg.region.end but I'm not getting one in this case.

llvm.dbg.region.start
void %llvm.dbg.region.start( { }* )
This intrinsic is used to define the beginning of a declarative scope (ex. block) for local language elements. It should be paired off with a closing %llvm.dbg.region.end. The function's single argument is the %llvm.dbg.block which is starting.

With the attached source

% llvm-gcc 20000223-1.c -g -c --emit-llvm
% opt -f -simplifycfg 20000223-1.o -o 20000223-1.o
% llvm-dis -f 20000223-1.o

the sole llvm.dbg.region.start appears to be unmatched.

[lattner]

The docs should be updated, if the end of function is not reachable, there may not be a dbg.region.end. I think this bug should be closed?

Out of curiousity, what code generator are you working on?

[llvmbot]

Thanks for the prompt reply. I'll investigate and report more tomorrow; an earlier fix I worked on simply caused the region.end for the function to implicitly imply the region.end for any unterminated region.start and this may be the way forward after all. That hit a problem where I was seeing region.end intrinsics for functions in the middle of a function - but then I had other optimisations running too.

[llvmbot]

File 1 of 2 for link issue

[llvmbot]

File 2 of 2 for link issue

[llvmbot]

The attached demo shows some missing subprogram end.region intrinsics; it is built with

llvm-gcc -save-temps -g -O0 -c -emit-llvm a.c -o a.bc
llvm-gcc -save-temps -g -O0 -c -emit-llvm b.c -o b.bc
llvm-ld -O1 a.bc b.bc -no-script -o c
llvm-dis -f c.bc

I attached these files in order to ask further questions but in composing the note I deduced a way to handle the missing records using a suitable stack which I think will work so it can probably be ignored for now!

There's a couple of other relevant comments on this bug:

. You asked about our code generator: it is targetting a proprietary VM and is based on the C and MSIL backends. As you may gather from the questions asked we are now implementing the debugging support aspects of it. Using the llvm compiler we have been able to get our toolchain implemented in a remarkably short period of time. In another job I worked on a port of gcc itself and this was far more laborious.

. There is the comment on this bug "Optimization of the code with debug information currently is not supported at all". llvm-gcc will disable debugging if -g and -O are specified simultaneously but we have been creating semi-optimised and debuggable code by: (a) passing -O0 to llvm-gcc; (b) passing the resultant bitcode file through opt; (c) passing optimisation flags to llvm-ld when linking. Is this recommended practice, or would it be more appropriate at this stage in the llvm development to ensure that optimisation and debugging are never used simultaneously?

Thanks!

[llvmbot]

bitcode file to run through simplifycfg optimisation pass
I have generally sorted out my code generator to handle missing region.end intrinsics by maintaining a stack. However this new example I am attaching shows that simplifycfg is causing regions to be generated which are not properly nested.

The bitcode attached has a number of subprograms in it but the first is the one of interest. At this point there has been no optimisation.

$ llvm-dis -f 20000605-3.bc
$ vi 20000605-3.ll

shows:

llvm.dbg.func.start llvm.dbg.subprogram
llvm.dbg.region.start llvm.dbg.block
llvm.dbg.region.end llvm.dbg.block
llvm.dbg.region.end llvm.dbg.subprogram

However, after

$ opt -f -simplifycfg 20000605-3.bc -o a.bc
$ llvm-dis -f a.bc
$ vi a.ll

you will see that these have been rearranged as

llvm.dbg.func.start llvm.dbg.subprogram
llvm.dbg.region.start llvm.dbg.block
llvm.dbg.region.end llvm.dbg.subprogram
llvm.dbg.region.end llvm.dbg.block

so the regions are no longer nested properly.

[lattner]

There is the comment on this bug "Optimization of the code with debug
information currently is not supported at all". llvm-gcc will disable debugging
if -g and -O are specified simultaneously but we have been creating
semi-optimised and debuggable code by: (a) passing -O0 to llvm-gcc; (b) passing
the resultant bitcode file through opt; (c) passing optimisation flags to
llvm-ld when linking. Is this recommended practice, or would it be more
appropriate at this stage in the llvm development to ensure that optimisation
and debugging are never used simultaneously?

The basic issue is that turning on debug info will cause severe code pessimization, and some people build with "-O2 -g" regularly. For llvm-gcc we can't take the risk that someone will do this, measure performance, then go away saying "llvm generates crappy code" :).

Clients of the debug info should be able to grok arbitrarily modified debug intrinsics though, so the optimizers should all be safe. Unnesting is something that your debug consumer will have to deal with, sorry! :(

[llvmbot]

IMO it is a bad mistake for -g to affect codegen at all. Even gcc gets this right. Consider:

User builds project with -O
Project doesn't work
User rebuilds project with -O -g
Project works
User curses and switches compilers

Or even worse:

User develops project with -O -g. It works fine.
Ship date nears, user rebuilds with -O
Project doesn't work

[lattner]

You're right, this is an open project.