Summary:
This patch adds an interface that uses an in-tree build of LLVM's libc
and libc++.
This is done using the `-DFLANG_RT_LIBC_PROVIDER=llvm` and
`-DFLANG_RT_LIBCXX_PROVIDER=llvm` options. Using `libc` works in terms
of CMake, but the LLVM libc is not yet complete enough to compile all
the files.
We hope that the timer can be cleared normally when the target-format is
`offload`, so as to avoid output like this:
```
===-------------------------------------------------------------------------===
Miscellaneous Ungrouped Timers
===-------------------------------------------------------------------------===
---Wall Time--- --- Name ---
----- Timer for perf llvm-ir -> isa and isa -> binary.
...
```
Co-authored-by: Guray Ozen <guray.ozen@gmail.com>
Previously, the `SHF_AARCH64_PURECODE` section flag wasn't added to the
implicitly created `.text` section if the module didn't contain any
functions, because no other section had the flag set.
Now, the `SHF_AARCH64_PURECODE` is always added if the "+execute-only"
target feature is set for the module during compilation.
This commit bulk updates all '.h', '.cl', '.inc', and '.cpp' files to
add any missing license headers.
The remaining files are generally CMake, SOURCES, scripts, markdown,
etc.
There are still some '.ll' files which may benefit from a license
header. I can't find an example of an LLVM IR file with a license header
in the rest of LLVM, but unlike most other (sub)projects, libclc has
examples of LLVM IR as source files, compiled and built into the
library.
Currently link_bc command depends on the bitcode file that is associated
with custom target builtins.link.clc-arch_suffix.
On windows we randomly see following error:
`
Generating builtins.link.clc-${ARCH}--.bc
Generating builtins.link.libspirv-${ARCH}.bc
error : The requested operation cannot be performed on a file with a
user-mapped section open.
`
I suspect that builtins.link.clc-${ARCH}--.bc file is being generated
while it is being used in link_bc.
This PR adds target-level dependency to ensure
builtins.link.clc-${ARCH}--.bc is generated first.
In the example below it is not clear that `(f32)` relates to `%arg2` and
not to `vector<2xf32>`:
```mlir
%0 = spirv.ImageSampleImplicitLod %arg0, %arg1 ["Lod"](%arg2) :
!spirv.sampled_image<...>, vector<2xf32>(f32) -> vector<4xf32>
```
This change applies new format to image operations and image operands
that does not use parenthesis and is less ambiguous:
```mlir
%0 = spirv.ImageSampleImplicitLod %arg0, %arg1 ["Lod"], %arg2 :
!spirv.sampled_image<...>, vector<2xf32>, f32 -> vector<4xf32>
```
This returns the type of data in the Block, which might be different
than the type of the expression or declaration we created the block for.
This lets us remove some special cases from CheckNewDeleteForms() and
CheckNewTypeMismatch().
Thanks to the example provided by MagentaTreehouse, I realized the
assertion I added in b8d1f3d6 didn't cover all valid cases like, when
inheriting from a class template specialization, the source of a
synthesized template parameter might be an implicit specialization,
whose inner function template is thus living at depth 0, for which we
don’t want it to overflow too.
I've decided to remove that assertion because I don't think it's
particularly useful: we're checking whether Depth = 0 parameters come
from function templates whose parents contribute no template parameters
to the depth, which is redundant given what the template depth already
means.
This also incorporates a drive-by fix for
https://github.com/llvm/llvm-project/pull/132061#discussion_r2008756718,
which I somehow missed.
During lldb testing on remote targets TestGdbRemoteForkNonStop.py
freezes because in this test we try to create file on remote machine
using absolute file path from local machine. This patch fixes this error
We have already ensured in 9cec2b246e719533723562950e56c292fe5dd5ad
that `INLINEASM_BR` output operands get spilled onto the stack, both
in the fallthrough path and in the indirect targets. Since reloads of
live-ins values into physical registers contextually happen after all
MIR instructions (and ops) have been visited, make sure such loads are
placed at the start of the block, but after prologues or `INLINEASM_BR`
spills, as otherwise this may cause stale values to be read from the
stack.
Fixes: #74483, #110251.
Function definition added in #131975 was missing 'Try' (do or do not ...). My guess is buildbots
mostly didn't trip because usage was gated by 'if (sizeof(uptr) ==
32)', which is rare among buildbots.
The function is only called by AsmPrinter, where there is a fallback
when lowerRelativeReference returns nullptr.
wasm and XCOFF could use the fallback code.
(lowerRelativeReference was introduced in 2016 (https://reviews.llvm.org/D17938)
for C++ relative vtables, but C++ relative vtables ended up using
dso_local_equivalent. llvm/test/MC/COFF/cross-section-relative.ll also
uses this.)
The `__is_referenceable` builtin has been removed from Clang, since all
its uses have been replaced by builtins themselves. This trait only
exists for GCC compatibility and to word around some issues in the other
traits. The non-builtin implementation has been refactored to use
variable templates instead, making the implementation much simpler.
We'e specialized `std::signbit` for signed and unsigned integral types
seperately, even though the optimizer can trivially figure out that
`unsigned_value < 0` always false is. This patch removes the
specialization, since there is really not much of a benefit to it.
A bare-bones version of LLVM's unique_function: this behaves like a
std::unique_function, except that it supports move only callable types.
This will be used in upcoming improvements to the ORC runtime.
The "extensible_" prefix on these files was inherited from LLVM, where it
distinguished the dynamic RTTI APIs from the LLVM's custom static RTTI APIs.
In the ORC runtime these files will be used to hold all of our RTTI APIs
(the current dynamic ones, and any static ones added in the future), so we
shouldn't use this prefix.
And use it for test cases that became constant-evaluation-suitable due
to P2562R1.
`TEST_STD_AT_LEAST_(20|23)_OR_RUNTIME_EVALUATED` are the precedents.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
DenseSet recently gained a range constructor:
DenseSet<T> Dest(llvm::from_range, Src);
This patch adds the same signature to SmallSetVector for consistency.
- Move LLVMDISubrangeTypeMetadataKind to end of LLVMMetadataKind enum.
Inserting a new enum constant in the middle of the enum breaks the ABI for
that enum. Commit e298fc2 introduced this issue, which was revealed because
the OCaml binding tests failed.
- Bring OCaml bindings up to date with LLVMMetadataKind enum.
Use the preferred "specifier" term for relocation specifier.
"Relocation modifier" suggests adjustments happen during the linker's
relocation step rather than the assembler's expression evaluation.
The term "relocation specifier" is preferred by Arm for :lower16: and
IBM AIX, and I am trying to standardize in MC.
Pull Request: https://github.com/llvm/llvm-project/pull/132565
ExtractElements are no-ops for scalar VPlans. Don't introduce them in
handleUncountableEarlyExit if the plan has only a scalar VF.
This fixes a crash trying to compute the cost of ExtractElement after 26ecf978951b79.
PR: https://github.com/llvm/llvm-project/pull/131604
