steakhal wrote: I simplified your implementation, and also identified a shortcoming of the `getSpecificAttr` that it didn't work with const attributes. I'll submit a fix for it separately to this PR.
The implementation looks pretty but there is a catch. And this is unfortunately a blocker issue. Quoting https://eel.is/c++draft/dcl.attr.assume: ```c++ int divide_by_32(int x) { [[assume(x >= 0)]]; return x/32; // The instructions produced for the division // may omit handling of negative values. } int f(int y) { [[assume(++y == 43)]]; // y is not incremented return y; // statement may be replaced with return 42; } ``` Because we eval the subexpressions of the assume arguments, their sideeffects sneaks in to the ExplodedGraph. So after all, this approach might not work out that well. We should have a look at what the codegen does with this attribute, or even with the builtin assume call - because we should do something very similar. We should gather the constraints and apply them, just like codegen does (I assume). I think a suitable place to start reading would be CGStmt.cpp `CodeGenFunction::EmitAttributedStmt()`. Basically, my idea now is more like: don't eval the expressions of the assume in the CFG, but only visit the AttributedStmt in the ExprEngine. When we would reach that, "do the same as codegen to get the constraints" and apply these constraints. Alternatively, we could take a snapshot of the Store and Environment before we would evaluate any expressions of the assume attribute and "restore" those after we finished with the AttributedStmt. If we would do this, we would be careful of sinking/"merging" all the paths we ended up creating while evaluating this Stmt. This is a lot more complicated, so I'd definitely try the previous approach before even considering this. https://github.com/llvm/llvm-project/pull/116462 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
