ruhrie / traceatlas Goto Github PK

View Code? Open in Web Editor NEW

8.0 8.0 4.0 12.22 MB

CMake 7.71% C 8.95% C++ 83.34%

traceatlas's People

Contributors

Stargazers

Watchers

Forkers

mackncheesiest benroywillis

traceatlas's Issues

Cartographer cannot parse trace from VOLK/stddev correctly

Cartographer just hands after starting. More debugging required to figure out if it is a problem with the cartographer or the tracer.

Do cross product of types and ops in pig

John thinks it would be good to do the cross product of the types and the ops. I have only done them individually.

It is the GetRatios function in Pig.cpp

No kernel detected

Could you try to detect the kernel in this example?
https://github.com/wohlbier/irex

I'm not getting anything and I wonder if my installation of TraceAtlas might be broken.

Thanks.

Unknown keys when parsing trace with cartographer

I have some commits built on top of a6faec5 (current master) but nothing that changes the cartographer core functionality.

With some codes, only some of the time, cartographer will die in execution at this throw 2 here

I added a print statement to see what the key is that's causing the error, and it usually seems to be some slightly messed up version of a legitimate key i.e.

Anyone have ideas how to stop it from happening? I think this bad key is legitimately encoded into the trace as repeated runs of cartographer with the same trace file lead to it dying at the same block, but rerunning the trace repeatedly sometimes seems to fix it.

Export Latent tik Globals

Some globals are declared from the original bitcode and they also need to be exported to the header.

Corrupted Trace Stream

Some applications will generate a corrupted zlib stream consistently. Since we are going to revamp the trace backend this isn't worth fixing.

Cartographer timing

The timing of the cartographer in both steps needs to be timed. Until then the SQL pushes will have -1 as their cartographer times.

Additional documentation requested

Could you please document what is meant by kernel types?

TypeFour, TypeOne, TypeThree, TypeThreeFive, TypeTwo, TypeTwoFive

Could you add documentation about how to generate kernel producer consumer relationships? A tool for graphical representation of the results would be great, but I understand if it's not in scope right now.

Thanks!

Globals are duplicating

Globals duplicate in kernel2 (kernel1 of the c) in the FunctionCall example.

[Feature Request] Investigate methods for standardizing kernel function signatures

In the current implementation of tik, the signatures for the autogenerated functions vary wildly depending on the kernel.
I'd like to get some input on methods that would enable normalizing these signatures into something that can be used in a runtime that automatically dispatches to these kernels.

For example, this kernel

i = 0; x = 1; y = 2; z = 3;
for (; i < 10000; i++) {
  x += y + z;
}

gives an LLVM function with four i32* arguments with the signature corresponding to Kernel_0(int* y, int* z, int* x, int* i)

While this kernel

for (i = 0; i < 10000; i++) {
  printf("test\n");
}

gives an LLVM function with a single i32* argument corresponding to i.

Assuming things are restricting to just kernels with int/common datatype arguments, a couple of ideas come to mind:

Refactor the function signature to accept a single array pointer with i.e. four elements and, in the init block of the kernel, assign the globals @0, @1, @2, @3 to the offsets in this array for each element
Refactor the function signature to use variadic arguments and build a runtime that can somehow dispatch to that (not even 100% sure it would be possible in C/C++ since there's no python-esque unpacking operator)

I think ideally, (1) would be the better solution as it could potentially generalize to things like mixed datatypes by making the input pointer act like a struct pointer, and the kernel's init code could unpack that struct into all the distinct variables that are used, but I would appreciate any input on the feasibility of this in general.

Question about tracing a library

I would like to do trace injection for a small subset of shared objects linked to a program, rather than all of the linked shared objects. Do you think this should be doable? I imagine that the main function also has to have a trace injected?

C++ application producing an empty trace

I'm not sure if there is some guidance with this, but I'm trying to trace a C++-based application, and while the bitcode seems to be getting annotated correctly with the basic block dump, etc, calls, the resulting trace is seemingly empty and produces nothing usable for cartographer/etc.

Has anyone here run into a similar issue when tracing C++ applications in the past? My first hunch would be that it's some subtlety around name mangling, but I'm not entirely sure.

It's an application with multiple source files, but I am choosing to only instrument and trace main.cpp, and my sequence of calls is essentially

clang++-9 -S -flto -fPIC -static main.cpp -o output-main.ll

opt-9 -load $TRACEHOME/lib/AtlasPasses.so \
  -EncodedTrace output-main.ll -S -o output-main-opt.ll

clang++-9 -static -fuse-ld=lld-9 -lpthread -lz -lm $TRACEHOME/lib/libAtlasBackend.a \
  <dependencies.cpp...> output-main-opt.ll -o output-main-tracer.out

./output-main-tracer.out

If further investigation is needed and it's not a simple fix, I'd be happy to provide the application I'm trying to trace.

Linking issue

Have you encountered this error?

[ 79%] Linking CXX executable 1DBlur-trace
cd /home/jgwohlbier/DSSoC/DASH/TraceAtlas/build/Tests/1DBlur && /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/cmake-3.17.1-juseoiihblddf34vz74c4ddqm6l2wphp/bin/cmake -E cmake_link_script CMakeFiles/1DBlur-trace.dir/link.txt --verbose=1
/DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/bin/clang++  -flto -O2 -g -DNDEBUG  -fuse-ld=lld opt.bc  -o 1DBlur-trace  -Wl,-rpath,/DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/z3-4.8.7-hr6if5gnjues5f5rtsu6hry34q4fmgwx/lib ../../lib/libAtlasBackend.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMIRReader.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMAsmParser.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMBitWriter.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMTransformUtils.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMAnalysis.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMObject.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMBitReader.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMBitstreamReader.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMMCParser.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMMC.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMDebugInfoCodeView.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMDebugInfoMSF.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMProfileData.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMCore.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMBinaryFormat.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMRemarks.a /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread -lm /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/z3-4.8.7-hr6if5gnjues5f5rtsu6hry34q4fmgwx/lib/libz3.so /DATA/SDH/packages/spack/opt/spack/linux-ubuntu18.04-broadwell/clang-9.0.1/llvm-9.0.1-mupwetisd3upwdfojfn6ztdmxmgfy3kz/lib/libLLVMDemangle.a ../../../vcpkg/installed/x64-linux/lib/libz.a 
module flag identifiers must be unique (or of 'require' type)
!"EnableSplitLTOUnit"
LLVM ERROR: Broken module found, compilation aborted!
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
Tests/1DBlur/CMakeFiles/1DBlur-trace.dir/build.make:115: recipe for target 'Tests/1DBlur/1DBlur-trace' failed
make[2]: *** [Tests/1DBlur/1DBlur-trace] Error 1
make[2]: Leaving directory '/home/jgwohlbier/DSSoC/DASH/TraceAtlas/build'
CMakeFiles/Makefile2:827: recipe for target 'Tests/1DBlur/CMakeFiles/1DBlur-trace.dir/all' failed
make[1]: *** [Tests/1DBlur/CMakeFiles/1DBlur-trace.dir/all] Error 2
make[1]: Leaving directory '/home/jgwohlbier/DSSoC/DASH/TraceAtlas/build'
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

Predecessors are Null

Some basic blocks are left behind that belonged to a function that was removed. A work around is in place, but this shouldn't happen.