fetch variable names through debugInfo attached to load instructors

Clang Frontend Using Clang
#1

Hello All,

I read the documentation and I was able to fetch the variable names and source locations attached to metadata for call instructions (@llvm.dbg.declare) using dyn_cast. I wanted to check if we could fetch the variable names in the load/gep instructors using debugInfo. I want to collect the use variable object details within the function.

I could only fetch the source locations (not the variable names) using !dbg attached to the load instructions. Any pointers if that is allowed.

C code:

int foo (bar_t *b, int len)

{

if (b == (bar_t *)NULL) {

return 0;

}

return -1;

}

IR optimised code through LTO:

; Function Attrs: noinline nounwind optnone uwtable

define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 {

%3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64]

%4 = add i64 %3, 1

%5 = alloca i32, align 4

%6 = alloca % struct.bar_t*, align 8

%7 = alloca i32, align 4

store % struct.bar_t* %0, % struct.bar_t** %6, align 8

call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata !11, metadata !DIExpression()), !dbg !12

store i32 %1, i32* %7, align 4

call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata !DIExpression()), !dbg !14

%8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15

%9 = icmp eq % struct.bar_t* %8, null, !dbg !16

br i1 %9, label %10, label %11, !dbg !17

Many Thanks.

#2

You’d have to analyze the dbg.declares and track that they refer to the same thing as the geps/loads you’re interested in - from the dbg.declares (& dbg.values) you can follow those to find the variables they refer to.

#3

Thanks! It works.

One sub-question: How do we analyze the member dereferenced struct variables as dbg.declares only has the declaration info as inside the function the struct variable types could have members dereferenced as well.

Example:

https://godbolt.org/z/zaeYn9do7

dbg.declares have use_var info, i would like to fetch address.id as well.

#4

Thanks! It works.

One sub-question: How do we analyze the member dereferenced struct variables as dbg.declares only has the declaration info as inside the function the struct variable types could have members dereferenced as well.

Example:

https://godbolt.org/z/zaeYn9do7

dbg.declares have use_var info, i would like to fetch address.id as well.

You’d have to do some sort of alias analysis, I guess - seeing that the load is from a pointer derived from the pointer that the alloca/dbg.declare describes - analyzing what offset from that is loaded, using the DI metadata to figure out which field that offset corresponds to.

In general optimizations shouldn’t try to do this - optimizations should be based on the IR alone, without attempting to be aware of the source constructs used to create them.
For source analysis - the IR isn’t a great tool for that, for the sort of reasons you’re seeing here, and the analysis should probably be written in terms of Clang’s AST instead.

  • Dave