-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the llvm.experimental.noalias.scope.decl
intrinsic
#1196
Comments
FWIW, there are some interesting things that handling metadata during symbolic execution can enable, such as checking validity of debug info a la this work: https://convolv.es/talks/testing-debug-info/ I don't think it should weigh too much on our deliberations about this issue, but it could be a gentle point in favor of leaving the door open for processing metadata. It also occurs to me that actually processing these declarations might help by allowing things like under-constrained symbolic execution to respect/check aliasing requirements. |
Sooner or later there'll be a spec you can't prove unless you can reason about (non)aliasing of pointers, so I'd agree with the last part. FWIW |
Thinking about this some more, I don't think that encoding That being said, I'm going to pursue the aforementioned expedient fix in an upcoming patch. If we want to support no-alias reasoning at a deeper level in the future, we can implement the |
llvm.experimental.noalias.scope.decl
intrinsic and metadata
valuesllvm.experimental.noalias.scope.decl
intrinsic
….assign This adds `llvm.experimental.noalias.scope.decl` and `llvm.dbg.assign` to the list of LLVM intrinsics that `crucible-llvm` skips over during simulation. Doing so unlocks more support for recent LLVM versions. It is conceivable that we may want to reason about these intrinsics at a deeper level some day. If so, see: * #1196 (comment) for how this would be done for `llvm.experimental.noalias.scope.decl` * #1204 (comment) for how this would be done for `llvm.dbg.assign` Fixes #1196. Fixes #1204.
….assign (#1205) This adds `llvm.experimental.noalias.scope.decl` and `llvm.dbg.assign` to the list of LLVM intrinsics that `crucible-llvm` skips over during simulation. Doing so unlocks more support for recent LLVM versions. It is conceivable that we may want to reason about these intrinsics at a deeper level some day. If so, see: * #1196 (comment) for how this would be done for `llvm.experimental.noalias.scope.decl` * #1204 (comment) for how this would be done for `llvm.dbg.assign` Fixes #1196. Fixes #1204.
C has a
restrict
mechanism that lets you indicate whether two pointers cannot alias. Here is an example based off of these slides:Prior to LLVM 12,
restrict
would compile to anoalias
annotation, whichcrucible-llvm
ignores¹:In LLVM 12 or later, however, the
noalias
annotation was replaced with a dedicatedllvm.experimental.noalias.scope.decl
intrinsic. Here is a standalone program that can be used to make Clang emit this intrinsic:Clang 14.0.0 will compile this to:
Unfortunately,
crucible-llvm
cannot handle this intrinsic out of the box:The problem is revealed in the
unsupported LLVM value: ValMd (ValMdNode [Just (ValMdRef 24)]) of type metadata
part of the error: thellvm.experimental.noalias.scope.decl
intrinsic takes ametadata
value as an argument, andcrucible-llvm
currently does not support any intrinsics that acceptmetadata
values as arguments². In fact,crucible-llvm
doesn't even support translatingmetadata
values, which is what leads to the error message above.The most expedient course of action would be to figure out how to make
crucible-llvm
treat calls to this intrinsic as a no-op. The main barrier is figuring out how to translatemetadata
values. Perhaps these can be translated to a trivial Crucible representation (e.g.,UnitRepr
).¹Perhaps
crucible-llvm
shouldn't ignore this, but that's a discussion for another issue.²Strictly speaking,
crucible-llvm
does handle somellvm.dbg.*
intrinsics that acceptmetadata
values as arguments, but these are done in a very ad hoc, special-cased fashion. See this code.The text was updated successfully, but these errors were encountered: