[LLVMdev] should InstCombine preserve @llvm.assume?

Jingyue Wu jingyue at google.com
Tue Jun 9 23:56:54 PDT 2015


Hi,

I have some WIP that leverages @llvm.assume in some optimization passes
other than InstCombine. However, it doesn't work yet because InstCombine
removes @llvm.assume calls that are useful for later optimizations. For
example, given

define i32 @foo(i32 %a, i32 %b) {
  %sum = add i32 %a, %b
  %1 = icmp sge i32 %sum, 0
  call void @llvm.assume(i1 %1)
  ret i32 %sum
}

"opt -instcombine" emits

define i32 @foo(i32 %a, i32 %b) {
  %sum = add i32 %a, %b
  ret i32 %sum
}

removing the @llvm.assume call so later optimizations won't know sum is
non-negative any more. (Note that the opt I use here is with
http://reviews.llvm.org/D10283 patched. This patch fixes a bug in
ValueTracking).

The reasons that InstCombine removes this assume call are:
1) SimplifyICmpInst proves %1 is true based on the assume call.
2) then, InstCombine (
http://llvm.org/docs/doxygen/html/InstCombineCompares_8cpp_source.html#l02649)
replaces all uses of %1 with true including the use in the assume call.
3) Somewhere later, llvm.assume(true) is considered trivially dead and thus
removed from the IR.

Step 2 looks particularly problematic to me. Removing @llvm.assume
essentially throws away the base of the proof so we won't be able to make
the same proof any more.

How can we fix this issue? One heavy-handed approach is, instead of RAUW
the icmp, we only replace the uses that are not by @llvm.assume. But I have
two concerns.

1) what if the icmp is not directly used by an @llvm.assume? e.g., if we
proved a >= 0 and that condition is used in assume(a >= 0 || b >= 0),
should we keep (a >= 0) in case later passes use them? If yes, we would
probably have to recursively traverse def-use chains. If no, some
assumption is again lost after instcombine.

2) what if the kept assumes are not leveraged later at all? These assumes
bump up values' refcounts and could potentially hurt optimizations. This
looks like a problem for adding @llvm.assume in general. Maybe users should
be aware of these trade-offs when adding __builtin_assumes in their source
code.

Thoughts?

Thanks,
Jingyue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150609/33d30f0e/attachment.html>


More information about the llvm-dev mailing list