[llvm-dev] attribute of intrinsic function

[Xiangyang Guo via llvm-dev]

Hi,

When I define an intrinsic function with memory write permission, my
assumption is that we can either attach [IntrReadWriteArgMem] or [] to the
intrinsic function. Based on the comment of the source code ,
"IntrReadWriteArgMem - This intrinsic reads and writes only from memory
that one of its arguments points to, but may access an unspecified amount."
"If no property is set, the worst case is assumed (it may read and write
any memory it can get access to and it may have other side effects)".

But when I define the intrinsic function with different attributes, there
is no difference when I dump the IR. For example, two intrinsic functions
are

def int_foo5 : Intrinsic<[], [llvm_ptr_ty], [IntrReadWriteArgMem]>;
def int_foo6 : Intrinsic<[], [llvm_ptr_ty], []>;

Then I write a very simple module, in each module the intrinsic function is
called twice as shown below:

/******the intrinsic function foo5 is used******/
; Function Attrs: nounwind
define void @_Z3fooPi(i8* %a) #0 {
  call void @llvm.foo5(i8* %a)
  call void @llvm.foo5(i8* %a)
  ret void
}
; Function Attrs: nounwind
declare void @llvm.foo5(i8*) #0
attributes #0 = { nounwind }


/****** the intrinsic function foo6 is used******/
; Function Attrs: nounwind
define void @_Z3fooPi(i8* %a) #0 {
  call void @llvm.foo6(i8* %a)
  call void @llvm.foo6(i8* %a)
  ret void
}
; Function Attrs: nounwind
declare void @llvm.foo6(i8*) #0
attributes #0 = { nounwind }

And my when I apply -O3 optimization level for these two bitcode, I hope
the second call can be eliminated. But from the result, it doesn't. For
intrinsic functio foo5, I don't understand it. I mean, when I apply
[IntrReadWriteArgMem] to this intrinsic function, I hope the LLVM can know
the second one is redundant because nothing is changed. Can you tell why
LLVM cannot optimize it in this case?

Any input is appreciable.

Regards,

Xiangyang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160324/6f2c51ca/attachment.html>