On Tue, May 25, 2021 at 1:13 PM Bella V <bellavistagh...@gmail.com> wrote:
> 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 > > > On Thu, May 20, 2021 at 12:25 PM David Blaikie <dblai...@gmail.com> wrote: > >> 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. >> >> On Thu, May 20, 2021 at 12:18 PM Bella V via cfe-users < >> cfe-users@lists.llvm.org> wrote: >> >>> 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<DbgVariableIntrinsic>. 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. >>> _______________________________________________ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >>> >>
_______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
