[llvm-dev] Why is this block of instructions generated?

[Dipanjan Das via llvm-dev]

The DataFlowSanitizer pass on LLVM 3.8.0, 64 bit (Ubuntu 16.04.2) generates
the following IR from source:

======================================
test.c
======================================
#include <sanitizer/dfsan_interface.h>

int main(void) {
  int i = 1;

  dfsan_label i_label = dfsan_create_label("i", 0);
  dfsan_set_label(i_label, &i, sizeof(i));

  return 0;
}

======================================
clang -c -emit-llvm -fsanitize=dataflow test.c -o test.bc
llvm-dis test.bc
======================================

test.ll
======================================

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
  %0 = alloca i16
  %retval = alloca i32, align 4
  %i = alloca i32, align 4
  %1 = alloca i16
  %i_label = alloca i16, align 2
  store i16 0, i16* %0
  store i32 0, i32* %retval, align 4

  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  %2 = ptrtoint i32* %i to i64
  %3 = and i64 %2, -123145302310913
  %4 = mul i64 %3, 2
  %5 = inttoptr i64 %4 to i16*
  %6 = bitcast i16* %5 to i64*
  store i64 0, i64* %6, align 2
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

  store i32 1, i32* %i, align 4
  %call = call zeroext i16 @dfsan_create_label(i8* getelementptr inbounds
([2 x i8], [2 x i8]* @.str, i32 0, i32 0), i8* null)
  store i16 0, i16* %1
  store i16 %call, i16* %i_label, align 2
  %7 = load i16, i16* %1
  %8 = load i16, i16* %i_label, align 2
  %9 = bitcast i32* %i to i8*
  call void @dfsan_set_label(i16 zeroext %8, i8* %9, i64 4)
  ret i32 0
}

======================================

I don't understand why the block of instruction I separated out  is being
generated. Looking at the Transform/Instrumentation/DataFlowsanitizer.cpp,
I can't find the code that inserts the instrumentation above. Can anyone
explain this behavior?

-- 

Thanks & Regards,
Dipanjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170620/eb517c8c/attachment.html>