[llvm-dev] Early CSE clobbering llvm.assume

[Josh Klontz via llvm-dev]

Here's a minimum reproducing example (attached and inline below):

define i32 @foo(i32*) {
entry:
  %1 = load i32, i32* %0
  %2 = icmp eq i32 %1, 3
  call void @llvm.assume(i1 %2)
  %3 = load i32, i32* %0
  ret i32 %3
}

Both -early-cse and -gvn independently simplify this IR to:

define i32 @foo(i32*) {
entry:
  %1 = load i32, i32* %0
  ret i32 %1
}

Whereas I think it would be more correct to simplify it to:

define i32 @foo(i32*) {
entry:
  %1 = load i32, i32* %0
  %2 = icmp eq i32 %1, 3
  call void @llvm.assume(i1 %2)
  ret i32 %1
}

And then:

define i32 @foo(i32*) {
entry:
  ret i32 3
}

Both -early-cse and -gvn appear capable of this final optimization, but get
stuck doing the wrong thing when given the initial code with the redundant
load.

v/r,
Josh

On Fri, Jun 10, 2016 at 11:42 AM, Josh Klontz <josh.klontz at gmail.com> wrote:

> As of llvm 3.8, the early CSE pass seems to remove llvm.assume intrinsics.
> Is this the expected behavior?
>
> I've attached as small-ish example of this happening in my production code.
>
>     $ opt -early-cse before-early-cse.ll -S > after-early-cse.ll
>
> Note the use of the assume intrinsic indicating that the loaded value
> %channels equals 3. In a later pass I replace the load instruction with the
> constant value. This approach worked in llvm 3.7. I can solve the issue by
> moving my pass before early CSE if need be.
>
> v/r,
> Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160610/d881d19d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assume_constant.ll
Type: application/octet-stream
Size: 318 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160610/d881d19d/attachment.obj>