CMAKE_SYSROOT works fine here, and `sysroot.py make-fake`
borders on trivial here, but I suppose it's still nice
to have a consistent script to set these up across platforms.
And these are the platforms where we can do real sysroot management one
day.
Differential Revision: https://reviews.llvm.org/D96882
Also add a script for sysroot management. For now, it can only create
fake sysroots that just symlink to local folders. This is useful for
testing.
Differential Revision: https://reviews.llvm.org/D96868
In the future Windows will enable Control-flow Enforcement Technology (CET aka shadow stacks). To protect the path where the context is updated during exception handling, the binary is required to enumerate valid unwind entrypoints in a dedicated section which is validated when the context is being set during exception handling.
This change allows llvm to generate the section that contains the appropriate symbol references in the form expected by the msvc linker.
This feature is enabled through a new module flag, ehcontguard, which was modelled on the cfguard flag.
The change includes a test that when the module flag is enabled the section is correctly generated.
The set of exception continuation information includes returns from exceptional control flow (catchret in llvm).
In order to collect catchret we:
1) Includes an additional flag on machine basic blocks to indicate that the given block is the target of a catchret operation,
2) Introduces a new machine function pass to insert and collect symbols at the start of each block, and
3) Combines these targets with the other EHCont targets that were already being collected.
Change originally authored by Daniel Frampton <dframpto@microsoft.com>
For more details, see MSVC documentation for `/guard:ehcont`
https://docs.microsoft.com/en-us/cpp/build/reference/guard-enable-eh-continuation-metadata
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D94835
This patch adds a pass to replace calls to vector intrinsics (i.e., LLVM
intrinsics operating on vector operands) with calls to a vector library.
Currently, calls to LLVM intrinsics are only replaced with calls to vector
libraries when scalar calls to intrinsics are vectorized by the Loop- or
SLP-Vectorizer.
With this pass, it is now possible to replace calls to LLVM intrinsics
already operating on vector operands, e.g., if such code was generated
by MLIR. For the replacement, information from the TargetLibraryInfo,
e.g., as specified via -vector-library is used.
This is a re-try of the original commit 2303e93e66 that was reverted
due to pass manager problems. Other minor changes have also been made.
Differential Revision: https://reviews.llvm.org/D95373
- Usual cross-compilation fix: s/target_/current_/g
- Define _LIBUNWIND_IS_NATIVE_ONLY to enable unwinding past
functions with return pointer authentication.
- Android needs two libunwind static libraries: one with symbols exported and
one without. These both need to be in the same build tree so
the libunwind_hermetic_static_library configuration option doesn't
help here. Replace it with build rules that build both libraries.
- Install the libraries in the location that Android expects them to be.
Differential Revision: https://reviews.llvm.org/D96563
This patch adds a pass to replace calls to vector intrinsics
(i.e., LLVM intrinsics operating on vector operands) with
calls to a vector library.
Currently, calls to LLVM intrinsics are only replaced with
calls to vector libraries when scalar calls to intrinsics are
vectorized by the Loop- or SLP-Vectorizer.
With this pass, it is now possible to replace calls to LLVM
intrinsics already operating on vector operands, e.g., if
such code was generated by MLIR. For the replacement,
information from the TargetLibraryInfo, e.g., as specified
via -vector-library is used.
Differential Revision: https://reviews.llvm.org/D95373
We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.
Differential Revision: https://reviews.llvm.org/D95956
