Can't get a constant or global slot for this (Help wanted)

[rdevans0]

I'm attempting to run a rather complex program and am unable to obtain a trace using LLVM-Tracer. Would like to know how to modify my code/ or the tracer in order to get it to work with gem5-aladdin.

The error I am receiving is:

SlotTracker.h:331: int SlotTracker::getLocalSlot(const llvm::Value*): 
Assertion '!isa<Constant>(V) && "Can't get a constant or global slot with this!"' failed.

I've ruled the issue down to something with the following C code:

COLrec deserializeCOLrec(FILE* os) {
    char line[256];
    int item = 0;
    COLrec c;
    size_t *data;
    while (fgets(line, sizeof(line), os) != NULL && item < 23) {
        if (line[0] == '#')
            continue;
        switch (item){
            case 0: c.id = deserializeStr(line); break;
            case 1: c.width = deserializeUint(line); break;
            ... /* Elided some code for brevity */
            case 17:
                fseek(os, -strlen(line), SEEK_CUR);
                c.heap = deserializeHeap(os);
                break;
            default:
                break; // DONE
        }
        item++;
    }
    return c;
}

The associated llvm IR for the entry block is as follows:

; Function Attrs: nounwind uwtable
define void @deserializeCOLrec(%struct.COLrec* noalias nocapture sret %agg.result, %struct._IO_FILE* %os) #0 {
  %line = alloca [256 x i8], align 16
  %c.sroa.21 = alloca [3 x i8], align 1
  %c.sroa.28 = alloca %struct.Heap, align 8
 ; PROBLEM LINE HERE vv
  %1 = alloca %struct.Heap, align 8
  call void @llvm.dbg.value(metadata !{%struct._IO_FILE* %os}, i64 0, metadata !334), !dbg !692
  %2 = getelementptr inbounds [256 x i8]* %line, i64 0, i64 0, !dbg !693
  call void @llvm.lifetime.start(i64 256, i8* %2) #5, !dbg !693
  call void @llvm.dbg.declare(metadata !{[256 x i8]* %line}, metadata !335), !dbg !693
  call void @llvm.dbg.value(metadata !13, i64 0, metadata !336), !dbg !694
  %3 = getelementptr inbounds [3 x i8]* %c.sroa.21, i64 0, i64 0, !dbg !695
  call void @llvm.lifetime.start(i64 3, i8* %3), !dbg !695
  %4 = bitcast %struct.Heap* %c.sroa.28 to i8*, !dbg !695
  call void @llvm.lifetime.start(i64 56, i8* %4), !dbg !695
  call void @llvm.dbg.declare(metadata !696, metadata !337), !dbg !695
  %5 = bitcast %struct.Heap* %1 to i8*, !dbg !697
  br label %.outer, !dbg !700

[EDIT] I should add that this code is simply part of the setup for my benchmark, it's not actually part of the section I've highlighted using the WORKLOAD variable.

[rdevans0]

For what it's worth, I didn't manage to fix this issue, but was able to circumvent it somewhat. If I compile just this file at -O0 it works fine.

I am fairly certain the problem is arising from the SROA pass in llvm, so the next step would be to try using opt to optimize the llvm-bitcode without using the SROA pass.

[xyzsam]

Hi Dave,

Sorry for the delayed reply. Thanks for letting us know about this. I believe that we have always required compilation with -O0. You can check out the new playground directory that has a Makefile and test file set up. It was added so people could experiment with the tracer. I will try to take a look at the problem in a day or two.

Sam

On Tue, Aug 22, 2017, 1:19 PM Dave Evans notifications@github.com wrote:

For what it's worth, I didn't manage to fix this issue, but was able to circumvent it somewhat. If I compile just this file at -O0 it works fine.

I am fairly certain the problem is arising from the SROA pass in llvm, so the next step would be to try using opt to optimize the llvm-bitcode without using the SROA pass.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ysshao/LLVM-Tracer/issues/22#issuecomment-324094082, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSxXA1GB0M_-EpBWfvuzrWkukYiOvGQks5saw2igaJpZM4O4L48 .

-- Thanks,

Sam Xi Harvard University Computer Science, Ph.D. Candidate http://www.samxi.org

[rdevans0]

Hey Sam,

The default optimization level for the %-opt.llvm files is -O1, which makes sense as -O0 is extremely far off in terms of performance.

playground/Makefile.tracer:50
%-opt.llvm: %.c labelmap
    clang -static -g -O1 -S -fno-slp-vectorize ...

Just ask if you want me to provide the files that produce the error.

[xyzsam]

HI Dave,

You said that the problematic code is just part of the setup for your benchmark, not the part that is actually getting instrumented, right? If that is the case, it is more likely to be an issue with LLVM itself. We're using a pretty old version of LLVM, unfortunately, and it would take a fair amount of work to update to a newer version. If it is an LLVM issue, I'm afraid the only way is to workaround this in the code itself. If you could send me the files that produce the error, I can verify whether it's a tracer bug or not.

Sam

[xyzsam]

Closing due to lack of discussion.