Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial LLVM 7 port #149

Merged
merged 3 commits into from Oct 15, 2018
Merged

Initial LLVM 7 port #149

merged 3 commits into from Oct 15, 2018

Conversation

mlen
Copy link
Contributor

@mlen mlen commented Oct 9, 2018

This CL consists of the minimal number of changes to compile bpftrace on LLVM 7.
I checked few oneliners and they all appear to work fine, but codegen specs are broken (probably due to different LLVM version).
LLVM 7 API is incompatible with previous versions, so few ifdefs will be needed to support both.

To Do:

  • Fix codegen tests
  • Fix build for older LLVM

@brendangregg
Copy link
Contributor

Thanks! yes, I think ifdefs will be needed so it can compile on llvm 5 (which we've been doing on Ubuntu), llvm 6 (which I know is commonly available in another major environment) and llvm 7.

It's been suggested that the LLVM C API is more stable than the C++ one, and might help with this, but I haven't investigated switching to it yet.

@cmarcelo
Copy link

Have you tried this without -DSTATIC_LINKING?

I'm having failures like:

[ 39%] Linking CXX executable bpftrace
/usr/bin/ld: ast/libast.a(codegen_llvm.cpp.o):(.rodata._ZTIN8bpftrace13MemoryManagerE[_ZTIN8bpftrace13MemoryManagerE]+0x10): undefined reference to `typeinfo for llvm::SectionMemoryManager'
/usr/bin/ld: ast/libast.a(codegen_llvm.cpp.o):(.rodata._ZTIN4llvm3orc22LegacyLookupFnResolverIZN8bpftrace6BpfOrcC4EPNS_13TargetMachineEEUlRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE_EE[_ZTIN4llvm3orc22LegacyLookupFnResolverIZN8bpftrace6BpfOrcC4EPNS_13TargetMachineEEUlRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE_EE]+0x10): undefined reference to `typeinfo for llvm::orc::SymbolResolver'
collect2: error: ld returned 1 exit status

I've noted that my LLVM is compiled without RTTI (which I'm is the default), but bpftrace is compiled with RTTI enabled (it uses it in some parser related code). Maybe that's behind this issue.

@mlen
Copy link
Contributor Author

mlen commented Oct 10, 2018

@cmarcelo I'm using it with the default flags and have no problem building it. I'm currently using Arch, which appears to ship typeinfo. Which distro are you using?

@brendangregg I chatted with a friend who did a lot of development with LLVM and it appears that the only way to support multiple major versions is to use ifdefs. This leads to another issue: codegen specs compare generated LLIL with expected output, which simply doesn't work with different LLVM versions. One way to solve it would be to have separate codegen specs for each major.

@brendangregg
Copy link
Contributor

Ok, thanks, looks like this is the best solution for now. And yes, we've already discussed that tests/codegen.cpp is tied to the LLVM version: it'll need ifdefs. Since that's a lot of work, I'd be fine with an initial PR that did the ifdefs for src/ast like you just did, then follow up with another for the tests.

BTW, how I do those tests is to delete the LLVM output from the test and then run bpftrace_tests, and the diff warning tells me what I need to copy-n-paste into tests/codegen.cpp to make it pass (need to delete the /^+/ and extra 's from the diff output.)

@brendangregg
Copy link
Contributor

I tested this on llvm 5.0, and that environment still works.

@brendangregg
Copy link
Contributor

@yonghong-song did you want to check this out for your environment?

@brendangregg
Copy link
Contributor

@ajor might want to confirm this is the way to go as well...

@yonghong-song
Copy link

My cmake command does not have -DSTATIC_LINKING and even with cmake -DSTATIC_LINKING:BOOL=OFF .. it still failed with latest trunk.

@brendangregg
Copy link
Contributor

@yonghong-song are they the same failures? Can you copy-n-paste some? It may be that there's changes between llvm 7 and 8, and we need more ifdefs.

@ajor
Copy link
Member

ajor commented Oct 10, 2018

Yeah this approach seems fine to me.

The codegen tests are a bit of a mess at the moment (I don't think they pass for any LLVM version) so I wouldn't bother converting them yet. I'm planning to split up the massive codegen.cpp, so we could also split out the tests by LLVM version at the same time.

BTW, how I do those tests is to delete the LLVM output from the test and then run bpftrace_tests, and the diff warning tells me what I need to copy-n-paste into tests/codegen.cpp to make it pass (need to delete the /^+/ and extra 's from the diff output.)

Just to add: make sure you check the new IR output is sensible before copying it in!

@cmarcelo
Copy link

@mlen the issue was lack of RTTI in LLVM. It worked for me after I've compiled LLVM with that. I'm using Clear Linux.

@yonghong-song
Copy link

The error is the same as I posted in #159.

[ 15%] Building CXX object src/ast/CMakeFiles/ast.dir/ast.cpp.o
[ 16%] Building CXX object src/ast/CMakeFiles/ast.dir/codegen_llvm.cpp.o
In file included from /home/yhs/work/bpftrace/src/ast/codegen_llvm.cpp:1:
/home/yhs/work/bpftrace/src/bpforc.h:50:48: error: ‘ModuleHandleT’ in ‘class llvm::orc::IRCompileLayer<llvm::orc::RTDyldObjectLinkingLayer, 
llvm::orc::SimpleCompiler>’ does not name a type
   using ModuleHandle = decltype(CompileLayer)::ModuleHandleT;
                                                ^~~~~~~~~~~~~
/home/yhs/work/bpftrace/src/bpforc.h:65:3: error: ‘ModuleHandle’ does not name a type
   ModuleHandle addModule(std::unique_ptr<Module> M) {
   ^~~~~~~~~~~~
/home/yhs/work/bpftrace/src/bpforc.h: In constructor ‘bpftrace::BpfOrc::BpfOrc(llvm::TargetMachine*)’:
/home/yhs/work/bpftrace/src/bpforc.h:55:52: error: no matching function for call to ‘llvm::orc::RTDyldObjectLinkingLayer::RTDyldObjectLinkin
gLayer(bpftrace::BpfOrc::BpfOrc(llvm::TargetMachine*)::<lambda()>)’
       CompileLayer(ObjectLayer, SimpleCompiler(*TM))
                                                    ^
In file included from /home/yhs/work/bpftrace/src/bpforc.h:10,
                 from /home/yhs/work/bpftrace/src/ast/codegen_llvm.cpp:1:
/mnt/vol/engshare/third-party2/llvm-fb/stable/gcc-5-glibc-2.23/03859b5/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:240:3: no
te: candidate: ‘llvm::orc::RTDyldObjectLinkingLayer::RTDyldObjectLinkingLayer(llvm::orc::ExecutionSession&, llvm::orc::RTDyldObjectLinkingLa
yer::ResourcesGetter, llvm::orc::RTDyldObjectLinkingLayer::NotifyLoadedFtor, llvm::orc::RTDyldObjectLinkingLayer::NotifyFinalizedFtor)’
   RTDyldObjectLinkingLayer(
   ^~~~~~~~~~~~~~~~~~~~~~~~
/mnt/vol/engshare/third-party2/llvm-fb/stable/gcc-5-glibc-2.23/03859b5/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:240:3: no
te:   candidate expects 4 arguments, 1 provided

For your record, I did not compile llvm with turning on RTTI.

@mlen
Copy link
Contributor Author

mlen commented Oct 10, 2018

@yonghong-song are you sure you're using the code from my fork? It seems you're using current master of iovisor/bpftrace by looking at the error message.

@brendangregg
Copy link
Contributor

I tested this with the following llvm build:

apt-get install -y cmake gcc g++
git clone --depth 1 http://llvm.org/git/llvm.git
cd llvm
mkdir build; cd build
cmake -DLLVM_TARGETS_TO_BUILD="X86;BPF" -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON ..
make -j16
make install

and it builds.. but things don't run:

# ./src/bpftrace -e 'kprobe:do_nanosleep { @ = count(); }'
bpftrace: /mnt/src/llvm/lib/IR/Instructions.cpp:275: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed.
Aborted (core dumped)

# ./src/bpftrace -e 'kprobe:do_nanosleep { printf("hi\n"); }'
bpftrace: /mnt/src/llvm/lib/IR/Instructions.cpp:1162: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
Aborted (core dumped)

These changes might be enough for llvm 7 (I haven't tested that yet), but don't seem enough for llvm latest.

If the changes do fix llvm 7, then that's an improvement and we should merge them. Just need extra work for latest.

@mlen
Copy link
Contributor Author

mlen commented Oct 11, 2018

@brendangregg please let me clean this branch up a bit and fix the tests first – I should have time to do this tomorrow

@brendangregg
Copy link
Contributor

I tested on llvm 5 & 6, seems ok. On llvm 7 it builds ok, and most things work, but this core dumps:

# ./src/bpftrace -e 'tracepoint:block:block_rq_issue { @[comm] = hist(args->bytes); }'
Segmentation fault (core dumped)

stack:

(gdb) bt
#0  0x00007ff522df212f in ?? () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#1  0x00007ff522df5272 in ?? () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#2  0x00007ff522df5539 in ?? () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#3  0x00007ff522dfd17e in ?? () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#4  0x00007ff522e0430b in ?? () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#5  0x00007ff522e04966 in llvm::SelectionDAG::LegalizeTypes() () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#6  0x00007ff522edac77 in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#7  0x00007ff522edf596 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#8  0x00007ff522ee1b32 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#9  0x00007ff522b6b3c1 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#10 0x00007ff5229a95ff in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#11 0x00007ff5229a9803 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#12 0x00007ff5229a9210 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/lib/llvm-7/lib/libLLVM-7.so.1
#13 0x00000000005f00f5 in llvm::orc::SimpleCompiler::operator() (this=0x21cec48, M=...)
    at /usr/lib/llvm-7/include/llvm/ExecutionEngine/Orc/CompileUtils.h:68
#14 0x00000000005f73b0 in llvm::orc::IRCompileLayer<llvm::orc::RTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>::addModule (this=0x21cec40, K=1, 
    M=std::unique_ptr<llvm::Module> containing 0x21c9f80) at /usr/lib/llvm-7/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h:85
#15 0x00000000005f1911 in bpftrace::BpfOrc::addModule (this=0x21cea90, M=std::unique_ptr<llvm::Module> containing 0x0)
    at /mnt/src/bpftrace-private/src/bpforc.h:104
#16 0x00000000005f1831 in bpftrace::BpfOrc::compileModule (this=0x21cea90, M=std::unique_ptr<llvm::Module> containing 0x0)
    at /mnt/src/bpftrace-private/src/bpforc.h:98
#17 0x00000000005ebde7 in bpftrace::ast::CodegenLLVM::compile (this=0x7fff25406260, debug=bpftrace::DebugLevel::kNone, out=...)
    at /mnt/src/bpftrace-private/src/ast/codegen_llvm.cpp:1417
#18 0x00000000005ce89e in main (argc=3, argv=0x7fff25406658) at /mnt/src/bpftrace-private/src/main.cpp:177

FWIW, I added these lines to /etc/apt/sources.list to get llvm 7:

deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-7 main
deb-src http://apt.llvm.org/xenial/ llvm-toolchain-xenial-7 main

-d does print out debug info before core dumping:

# ./src/bpftrace -d -e 'tracepoint:block:block_rq_issue { @[comm] = hist(args->bytes); }'
#include <linux/types.h>
struct _tracepoint_block_block_rq_issue
{
  unsigned short common_type;
  unsigned char common_flags;
  unsigned char common_preempt_count;
  int common_pid;
  dev_t dev;
  sector_t sector;
  unsigned int nr_sector;
  unsigned int bytes;
  char rwbs[8];
  char comm[16];
  int data_loc_cmd;
};

Program
 tracepoint:block:block_rq_issue
  =
   map: @
    builtin: comm
   call: hist
    .
     dereference
      builtin: args
     bytes

; ModuleID = 'bpftrace'
source_filename = "bpftrace"
target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128"
target triple = "bpf-pc-linux"

; Function Attrs: nounwind
declare i64 @llvm.bpf.pseudo(i64, i64) #0

; Function Attrs: argmemonly nounwind
declare void @llvm.lifetime.start.p0i8(i64, i8* nocapture) #1

define i64 @"tracepoint:block:block_rq_issue"(i8*) local_unnamed_addr section "s_tracepoint:block:block_rq_issue_1" {
entry:
  %"@_val" = alloca i64, align 8
  %comm = alloca [16 x i8], align 1
  %"@_key" = alloca [24 x i8], align 1
  %_tracepoint_block_block_rq_issue.bytes = alloca i32, align 4
  %1 = add i8* %0, i64 28
  %2 = bitcast i32* %_tracepoint_block_block_rq_issue.bytes to i8*
  call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %2)
  %probe_read = call i64 inttoptr (i64 4 to i64 (i8*, i64, i8*)*)(i32* nonnull %_tracepoint_block_block_rq_issue.bytes, i64 4, i8* %1)
  %3 = load i32, i32* %_tracepoint_block_block_rq_issue.bytes, align 4
  call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %2)
  %4 = icmp sgt i32 %3, i64 65535
  %5 = zext i1 %4 to i64
  %6 = shl nuw nsw i64 %5, 4
  %7 = lshr i32 %3, i64 %6
  %8 = icmp sgt i64 %7, 255
  %9 = zext i1 %8 to i64
  %10 = shl nuw nsw i64 %9, 3
  %11 = lshr i64 %7, %10
  %12 = or i64 %10, %6
  %13 = icmp sgt i64 %11, 15
  %14 = zext i1 %13 to i64
  %15 = shl nuw nsw i64 %14, 2
  %16 = lshr i64 %11, %15
  %17 = or i64 %12, %15
  %18 = icmp sgt i64 %16, 3
  %19 = zext i1 %18 to i64
  %20 = shl nuw nsw i64 %19, 1
  %21 = lshr i64 %16, %20
  %22 = or i64 %17, %20
  %23 = icmp sgt i64 %21, 1
  %24 = zext i1 %23 to i64
  %25 = or i64 %22, %24
  %26 = getelementptr inbounds [24 x i8], [24 x i8]* %"@_key", i64 0, i64 0
  call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %26)
  %27 = getelementptr inbounds [16 x i8], [16 x i8]* %comm, i64 0, i64 0
  call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %27)
  call void @llvm.memset.p0i8.i64(i8* nonnull align 1 %27, i8 0, i64 16, i1 false)
  %get_comm = call i64 inttoptr (i64 16 to i64 (i8*, i64)*)([16 x i8]* nonnull %comm, i64 16)
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* nonnull align 1 %26, i8* nonnull align 1 %27, i64 16, i1 false)
  %28 = getelementptr inbounds [24 x i8], [24 x i8]* %"@_key", i64 0, i64 16
  store i64 %25, i8* %28, align 8
  %pseudo = call i64 @llvm.bpf.pseudo(i64 1, i64 1)
  %lookup_elem = call i8* inttoptr (i64 1 to i8* (i8*, i8*)*)(i64 %pseudo, [24 x i8]* nonnull %"@_key")
  %map_lookup_cond = icmp eq i8* %lookup_elem, null
  br i1 %map_lookup_cond, label %lookup_merge, label %lookup_success

lookup_success:                                   ; preds = %entry
  %29 = load i64, i8* %lookup_elem, align 8
  %phitmp = add i64 %29, 1
  br label %lookup_merge

lookup_merge:                                     ; preds = %entry, %lookup_success
  %lookup_elem_val.0 = phi i64 [ %phitmp, %lookup_success ], [ 1, %entry ]
  %30 = bitcast i64* %"@_val" to i8*
  call void @llvm.lifetime.start.p0i8(i64 -1, i8* nonnull %30)
  store i64 %lookup_elem_val.0, i64* %"@_val", align 8
  %pseudo1 = call i64 @llvm.bpf.pseudo(i64 1, i64 1)
  %update_elem = call i64 inttoptr (i64 2 to i64 (i8*, i8*, i8*, i64)*)(i64 %pseudo1, [24 x i8]* nonnull %"@_key", i64* nonnull %"@_val", i64 0)
  call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %26)
  call void @llvm.lifetime.end.p0i8(i64 -1, i8* nonnull %30)
  ret i64 0
}

; Function Attrs: argmemonly nounwind
declare void @llvm.lifetime.end.p0i8(i64, i8* nocapture) #1

; Function Attrs: argmemonly nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1) #1

; Function Attrs: argmemonly nounwind
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly, i8* nocapture readonly, i64, i1) #1

attributes #0 = { nounwind }
attributes #1 = { argmemonly nounwind }
Segmentation fault (core dumped)

@brendangregg
Copy link
Contributor

... and it is the args->bytes as the histogram value that is causing the crash. Other values work ok.

@mlen
Copy link
Contributor Author

mlen commented Oct 13, 2018

Another case I found with LLVM 7:

$ ./src/bpftrace -d -e 'tracepoint:block:block_rq_issue { @[comm] = max(args->bytes); }'                                                                                         
#include <linux/types.h>
struct _tracepoint_block_block_rq_issue
{
  unsigned short common_type;
  unsigned char common_flags;
  unsigned char common_preempt_count;
  int common_pid;
  dev_t dev;
  sector_t sector;
  unsigned int nr_sector;
  unsigned int bytes;
  char rwbs[8];
  char comm[16];
  int data_loc_cmd;
};

Program
 tracepoint:block:block_rq_issue
  =
   map: @
    builtin: comm
   call: max
    .
     dereference
      builtin: args
     bytes

bpftrace: /usr/include/llvm/IR/Instructions.h:1117: void llvm::ICmpInst::AssertOK(): Assertion `getOperand(0)->getType() == getOperand(1)->getType() && "Both operands to ICmp instruction are not of the same type!"' failed.

@brendangregg
Copy link
Contributor

Looks like llvm 7 is doing extra int type checks, breaking passing the 32-bit args->bytes to hist() (or lhist(), sum(), etc). Here's how I fixed it (tested on llvm 7 and llvm 5):

diff --git a/src/ast/codegen_llvm.cpp b/src/ast/codegen_llvm.cpp
index 40cf71a..e05cd83 100644
--- a/src/ast/codegen_llvm.cpp
+++ b/src/ast/codegen_llvm.cpp
@@ -164,6 +164,7 @@ void CodegenLLVM::visit(Call &call)
     AllocaInst *newval = b_.CreateAllocaBPF(map.type, map.ident + "_val");
 
     call.vargs->front()->accept(*this);
+    expr_ = b_.CreateIntCast(expr_, b_.getInt64Ty(), false); // promote int to 64-bit
     b_.CreateStore(b_.CreateAdd(expr_, oldval), newval);
     b_.CreateMapUpdateElem(map, key, newval);
 
@@ -183,6 +184,7 @@ void CodegenLLVM::visit(Call &call)
     // elements will always store on the first occurrance. Revent this later when printing.
     Function *parent = b_.GetInsertBlock()->getParent();
     call.vargs->front()->accept(*this);
+    expr_ = b_.CreateIntCast(expr_, b_.getInt64Ty(), false); // promote int to 64-bit
     Value *inverted = b_.CreateSub(b_.getInt64(0xffffffff), expr_);
     BasicBlock *lt = BasicBlock::Create(module_->getContext(), "min.lt", parent);
     BasicBlock *ge = BasicBlock::Create(module_->getContext(), "min.ge", parent);
@@ -207,6 +209,7 @@ void CodegenLLVM::visit(Call &call)
 
     Function *parent = b_.GetInsertBlock()->getParent();
     call.vargs->front()->accept(*this);
+    expr_ = b_.CreateIntCast(expr_, b_.getInt64Ty(), false); // promote int to 64-bit
     BasicBlock *lt = BasicBlock::Create(module_->getContext(), "min.lt", parent);
     BasicBlock *ge = BasicBlock::Create(module_->getContext(), "min.ge", parent);
     b_.CreateCondBr(b_.CreateICmpSGE(expr_, oldval), ge, lt);
@@ -239,6 +242,7 @@ void CodegenLLVM::visit(Call &call)
     Value *total_old = b_.CreateMapLookupElem(map, total_key);
     AllocaInst *total_new = b_.CreateAllocaBPF(map.type, map.ident + "_val");
     call.vargs->front()->accept(*this);
+    expr_ = b_.CreateIntCast(expr_, b_.getInt64Ty(), false); // promote int to 64-bit
     b_.CreateStore(b_.CreateAdd(expr_, total_old), total_new);
     b_.CreateMapUpdateElem(map, total_key, total_new);
     b_.CreateLifetimeEnd(total_key);
@@ -250,6 +254,7 @@ void CodegenLLVM::visit(Call &call)
   {
     Map &map = *call.map;
     call.vargs->front()->accept(*this);
+    expr_ = b_.CreateIntCast(expr_, b_.getInt64Ty(), false); // promote int to 64-bit
     Function *log2_func = module_->getFunction("log2");
     Value *log2 = b_.CreateCall(log2_func, expr_, "log2");
     AllocaInst *key = getHistMapKey(map, log2);
@@ -285,6 +290,12 @@ void CodegenLLVM::visit(Call &call)
     step_arg.accept(*this);
     step = expr_;
 
+    // promote int to 64-bit
+    value = b_.CreateIntCast(value, b_.getInt64Ty(), false);
+    min = b_.CreateIntCast(min, b_.getInt64Ty(), false);
+    max = b_.CreateIntCast(max, b_.getInt64Ty(), false);
+    step = b_.CreateIntCast(step, b_.getInt64Ty(), false);
+
     Value *linear = b_.CreateCall(linear_func, {value, min, max, step} , "linear");
 
     AllocaInst *key = getHistMapKey(map, linear);

The "promote int to 64-bit" comment is deliberate, so we can find these later (in case we rewrite that all in a better way).

@ajor how's that look? @mlen, if this also seems reasonable to you, can you include the above and test? thanks!

With #149 + the above diff, llvm 7 is working for me. CC @yonghong-song

@ajor
Copy link
Member

ajor commented Oct 15, 2018

Looks good to me

Apply Brendan's patch
@ajor ajor mentioned this pull request Oct 15, 2018
@mlen
Copy link
Contributor Author

mlen commented Oct 15, 2018

@brendangregg everything seems to work just fine after applying your patch

@brendangregg
Copy link
Contributor

Great, thanks, I'll merge unless someone says not to. Yes, I know we need to cleanup the codegen tests later (which have to deal with different llvm versions, too)...

@brendangregg brendangregg merged commit 51500df into bpftrace:master Oct 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants