about summary refs log tree commit diff homepage
path: root/test/Intrinsics
AgeCommit message (Collapse)Author
2022-06-30remove LLVM < 9Frank Busse
2022-06-26Intrinsics: Add support for @llvm.f{ma,muladd}.f*Lukáš Zaoral
2022-06-13tests: invoke LLVM tools through their corresponding macrosLukáš Zaoral
2022-03-17LLVM < 6 leftoversJulian Büning
2021-09-10llvm12: Implement llvm.abs intrinsicLukas Zaoral
The vector variants are not implemented at the moment. See: https://reviews.llvm.org/D84125 Co-authored-by: Lukas Zaoral <lzaoral@redhat.com> Co-authored-by: Martin Nowack <m.nowack@imperial.ac.uk>
2021-09-10llvm12: Implement llvm.{s,u}{max,min} intrinsicsLukas Zaoral
The vector variants are not implemented at the moment. See: https://reviews.llvm.org/D84125 Co-authored-by: Lukas Zaoral <lzaoral@redhat.com> Co-authored-by: Martin Nowack <m.nowack@imperial.ac.uk>
2021-05-04tests: adjust to new summary outputFrank Busse
2020-09-02More robust handling of unknown intrinsicsAlastair Reid
- If an unknown intrinsic appears in the bitcode file, it is reported but execution can proceed. - If an unknown intrinsic is encountered during execution of some path, - the intrinsic is reported - this path is treated as an error - execution of other paths can proceed To be more precise, there is a list of "known unknown intrinsics". Intrinsics not on this list will prevent execution.
2020-06-29Implement fshr/fshl intrinsicsAlastair Reid
Changes: - IntrinsicCleaner accepts fshr/fshl as accepted intrinsics - Executor::executeCall converts fshr/fshl to urem/zext/concat/shift/extract - Klee/main suppresses warnings about externals that are LLVM reserved (i.e., begin with "llvm.") - New test exercises 32 and 7 bit versions including oversize shift values Test values are based on LLVM's test for fshl/fshr - Changes that depend on existence of fshr/fshl are guarded by #if LLVM_VERSION_CODE >= LLVM_VERSION(7, 0) or ; REQUIRES: geq-llvm-7.0
2019-11-15Implement @llvm.is.constant() intrinsic handling and add a test for it.Gleb Popov
2019-11-07Handle llvm.objectsize explicitlyMartin Nowack
llvm.objectsize is used in several optimisation during compile time. Lowering these intrinsics took a conservative approach returning always the value for unknown. Instead, lower to the object's real size, if possible. Otherwise, a conservative value is used. Since LLVM 4.0, the function `llvm::lowerObjectSizeCall()` does exactly this. Use this function or preserve the old behaviour for older LLVM versions.
2019-10-31LLVM 9.0: fourth parameter for @llvm.objectsize()Julian Büning
2019-09-20Move intrinsics tests to the proper directoryMateusz Naściszewski
2019-05-28Implement handling of the llvm.fabs intrinsicFelix Rath
2019-03-21remove tests for LLVM <= 3.7Julian Büning
2019-03-12Fixed comments to objectsize.ll and objectsize.leq49.llCristian Cadar
2019-03-12Removed unneeded and confusing disable-opt option, reformatted Optimize() ↵Cristian Cadar
function and updated some .ll tests to use --optimize=false instead of --disable-opt
2018-10-26llvm5: test, change objectsizeJiri Slaby
@llvm.objectsize has now three aguments, so fix the tests accordingly. Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
2018-05-24test: add versions of some tests for LLVM 3.7Richard Trembecký
Clone some tests to have their 3.7 version. 'call's, 'load's and 'getelementptr's match the new specification in them. @andreamattavelli: Fixed test cases: BitCastAlias test cases included modification to alias specifications that require LLVM 3.8 [v2] added comments what was changed and why [v3] the new tests are without suffix, the old ones have ".leq36". Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
2017-07-23Updated test cases to reflect removal of LLVM 2.9Martin Nowack
2015-12-19Implement support for lowering the ``llvm.objectsize`` intrinsicDan Liew
introduced in LLVM 2.7. Previously KLEE would emit the following error message when ``IntrinsicLowering::LowerIntrinsicCall()`` was called on the intrinsic ``` LLVM ERROR: Code generator does not support intrinsic function 'llvm.objectsize.i64.p0i8'! ``` The ``IntrinsicCleaner`` pass now lowers this intrinsic to a constant integer depending on the second argument to the intrinsic. This corresponds to the case where the size of the object pointed to by the first argument is unknown. An alternative design would be to handle this intrinsic in the Executor where is actually possible to know the size of objects during execution. However that would be much more complicated because if the pointer is symbolic we would have to fork for every object that could be pointed to. The implementation is similar to #260 but we handle the second argument to the intrinsic correctly and also have a simple test case. Unfortunately we have to have a different version of the test case for LLVM 2.9 because the expected suffix for the intrinsic is different in LLVM 2.9.