Open Lancern opened 9 hours ago
I think you could solve in a simpler way this problem by involving the current "idiom recognition" and play with abstract interpretation to figure out the semantics of the code instead of looking at implementation details of !v.empty()
.
It would be just leveraging the current work already done in CIR static analysis to do high-level code optimization, not only bug detection as today.
A Motivating Example
Let's consider the following over-simplified code as a motivating example:
The current clang trunk emits the following code for the two functions above under
-O1
:A bit surprisingly clang (and LLVM) failed to optimize away the boundary check in function
foo
. The reason could be seen from the warning message clang emits:The
__builtin_assume
intrinsic function (and equivalently the C++23[[assume(expr)]]
attribute) is special because it explicitly prevents its operand from being evaluated. Thus, if clang determines the assume operand may carry any side effects, it just gives up and won't emit any optimization hints from the assume statement. In functionbar
, the assume operand is a simple and stupid id-expression which clang knows for sure would be free of side effects, so clang happily generates a load to the local variable and emits a call to@llvm.assume
. However, in functionfoo
, the assume operand is a suspicious function call expression which calls a function not explicitly marked as pure. Clang has to be conservative and assumes that the callee might have arbitrary side effects. Thus clang could not safely generate a call to the function, and it has to ignore the assume statement.It could be extremely tough, if not impossible, to resolve this problem in the original clang CodeGen, since you need to implement some kind of "inlining" to teach CodeGen that the call to
vector::empty
is free of side effects. I believe this is a case where ClangIR could help.Potential Solution
I'm writing down some rough ideas about the potential solution for the problem, in the hope that it could become more mature and doable with feedbacks and discussions.
The solution is to emit the assume statement into a new assume operation (let's name it
cir.assume_expr
here) that contains an "unevaluated" region:The
cir.assume_expr
operation has a region and no operands. The region is "unevaluated": code within the region will not evaluate with respect to the as-if rule. The region effectively contains code for evaluating the assume operand. The terminating operation of the region must be acir.yield
operation that yields a boolean value.When lowering, we handle the new operation in the following way:
If the region is pure (all operations in the region is pure), inline the region before the operation and replace the operation with an assume hint.
Otherwise, we just discard the operation.
It's pretty straightforward and mimics the original clang behavior.
The interesting part about the new operation is that it allows us to perform "inlining" in the region's code, and this allows us to reason about the purity of the assume operand across functions. AFAIK, @keryell recently is playing around (#1164) on the MLIR inliner with CIR. The inliner could inline the call to
vector::empty
in the region, which could transform the code above into something similar to:After inlining, the region becomes pure, which enables the lowering of the assume operation.