Age | Commit message (Collapse) | Author |
|
|
|
Co-authored-by: Daniel Schemmel <danielschemmel@users.noreply.github.com>
(cherry picked from commit 5d61fb6114bafbf67c59899d15e397684d4ceb28)
|
|
Similar functionality needs to be added using a new pass manager
|
|
`Intrinsic::flt_rounds` got removed
|
|
|
|
|
|
|
|
|
|
With recent LLVM versions, this should allow to link against dynamic LLVM
libraries.
|
|
... for LLVM 14 in [1] and has already been removed from the LLVM 15
branch in [2].
Some changes are only temporary to silence the warning though, as
Type::getPointerElementType() is planned to be removed as well. [3]
[1] https://reviews.llvm.org/D117885/new/
[2] https://github.com/llvm/llvm-project/commit/d593cf7
[3] https://llvm.org/docs/OpaquePointers.html#migration-instructions
|
|
|
|
|
|
LLVM became more complex, use LLVM's CMake functionality directly instead
of replicating this behaviour in KLEE's build system.
Use the correct build flags provided by LLVM itself.
This is influenced by the way LLVM is built in the first place.
Remove older CMake support (< 3.0).
|
|
strips out these intrinsics
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See: https://reviews.llvm.org/D105653
|
|
See: https://github.com/llvm/llvm-project/commit/6312c53870897435b38881795460ad9f34bf9819
|
|
Add i686 to the list of supporterd targets by this transformation pass.
|
|
RaiseAsm always created a target machine for the host target and not for
the bitcode one. Therefore, KLEE could crash on i686 bitcode as x86_64
target machine cannot be used to raise i686 assembly.
Fixes:
LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!
|
|
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>
|
|
See: https://reviews.llvm.org/D75670
|
|
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>
|
|
restoring old behavior without EH support
|
|
See: https://reviews.llvm.org/D84447
|
|
CallBase::getCalledValue has been deprecated by getCalledOperand since LLVM 8
and has been removed in LLVM 11
See: https://reviews.llvm.org/D78882
|
|
The same applies to SmallString.
See: llvm/llvm-project@777180a#diff-497ba4c0c527a125d382b51a34f32542
|
|
|
|
We implement the Itanium ABI unwinding base-API, and leave the
C++-specific parts to libcxxabi.
Co-authored-by: Lukas Wölfer <lukas.woelfer@rwth-aachen.de>
|
|
|
|
Global variables can't be a direct call target. Their values are read
and treated as indirect call targets.
|
|
This is in preparation for LLVM 11 as the llvm:CallSite class has been
removed.
|
|
- 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.
|
|
|
|
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
|
|
values
Inline asm used for memory barriers might use their operands and propagate them as
return value.
This is currently not supported. Tighten check for this condition and do not to
lift those inline asm instructions.
Fixes #1252
|
|
appropriate existing directories and a new directory Statistics; a few missing renames.
|
|
tly in lib/Core
|
|
|
|
introduced during the optimization step
|
|
Tracking function locations separately correctly without prefixing
it with a directory.
|
|
|
|
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.
|
|
|
|
|