maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Bitcode/function-encoding-rel-opera...

53 lines
1.4 KiB
LLVM
Raw Normal View History

Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
; Basic sanity test to check that instruction operands are encoded with
; relative IDs.
; RUN: llvm-as < %s | llvm-bcanalyzer -dump | FileCheck %s
verify-uselistorder: Force -preserve-bc-use-list-order llvm-svn: 216022
2014-08-20 05:08:27 +08:00
; RUN: verify-uselistorder < %s
Change encoding of instruction operands in bitcode binaries to be relative to the instruction position. The old encoding would give an absolute ID which counts up within a function, and only resets at the next function. I.e., Instead of having: ... = icmp eq i32 n-1, n-2 br i1 ..., label %bb1, label %bb2 it will now be roughly: ... = icmp eq i32 1, 2 br i1 1, label %bb1, label %bb2 This makes it so that ids remain relatively small and can be encoded in fewer bits. With this encoding, forward reference operands will be given negative-valued IDs. Use signed VBRs for the most common case of forward references, which is phi instructions. To retain backward compatibility we bump the bitcode version from 0 to 1 to distinguish between the different encodings. llvm-svn: 165739
2012-10-12 04:20:40 +08:00
; CHECK: FUNCTION_BLOCK
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_RET {{.*}}op0=1
define i32 @test_int_binops(i32 %a) nounwind {
entry:
%0 = add i32 %a, %a
%1 = sub i32 %0, %0
%2 = mul i32 %1, %1
ret i32 %2
}
; CHECK: FUNCTION_BLOCK
; CHECK: INST_CAST {{.*}}op0=1
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_BINOP {{.*}}op0=1 op1=1
; CHECK: INST_RET {{.*}}op0=1
define double @test_float_binops(i32 %a) nounwind {
%1 = sitofp i32 %a to double
%2 = fadd double %1, %1
%3 = fsub double %2, %2
%4 = fmul double %3, %3
%5 = fdiv double %4, %4
ret double %5
}
; CHECK: FUNCTION_BLOCK
; skip checking operands of INST_INBOUNDS_GEP since that depends on ordering
; between literals and the formal parameters.
; CHECK: INST_INBOUNDS_GEP {{.*}}
; CHECK: INST_LOAD {{.*}}op0=1 {{.*}}
; CHECK: INST_CMP2 op0=1 {{.*}}
; CHECK: INST_RET {{.*}}op0=1
define i1 @test_load(i32 %a, {i32, i32}* %ptr) nounwind {
entry:
%0 = getelementptr inbounds {i32, i32}* %ptr, i32 %a, i32 0
%1 = load i32* %0
%2 = icmp eq i32 %1, %a
ret i1 %2
}
Teach llvm-bcanalyzer to use one stream's BLOCKINFO to read another stream. This allows streams that only use BLOCKINFO for debugging purposes to omit the block entirely. As long as another stream is available with the correct BLOCKINFO, the first stream can still be analyzed and dumped. As part of this commit, BitstreamReader gets a move constructor and move assignment operator, as well as a takeBlockInfo method. llvm-svn: 216826
2014-08-31 01:07:55 +08:00
; CHECK: Stream type: LLVM IR