| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
single directive and firstprivate clause.
Semantic checks added to check the worksharing 'single' region closely nested inside a worksharing 'do' region. And also to check whether the DO iteration variable is a variable in Firstprivate clause.
Files:
check-directive-structure.h
check-omp-structure.h
check-omp-structure.cpp
Testcases:
omp-do01-positivecase.f90
omp-do01.f90
omp-do05-positivecase.f90
omp-do05.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D93205
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the ARMv8.7-A LS64 extension's intrinsics for 64 bytes
atomic loads and stores: `__arm_ld64b`, `__arm_st64b`, `__arm_st64bv`,
and `__arm_st64bv0`. These are selected into the LS64 instructions
LD64B, ST64B, ST64BV and ST64BV0, respectively.
Based on patches written by Simon Tatham.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D93232
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
static_cast for uint64_t to unsigned gives a MS VC build warning
for Windows:
warning C4309: 'static_cast': truncation of constant value
Use an explicit cast instead.
Change-Id: I692d335b4913070686a102780c1fb05b893a2f69
Differential Revision: https://reviews.llvm.org/D94592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test was marked as remote-only, which means it was run ~never, and
accumulated various problems. This commit modifies the test to run
locally and includes a couple of other fixes necessary to make it run:
- moves the "invoke" method into the "Base" test class
- adds []'s around the IP address in a couple more places to make things
work with IPv6
The test is now marked as skipped when running the remote test suite. It
would be possible to make it run both locally and remotely, but this
would require writing a lot special logic for the remote case, and that
is not worth it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Since [[ https://reviews.llvm.org/D94178 | the LLVMIntegerType was replaced with build-in integer type ]], the usage in the tutorial should be also updated accordingly.
We need to update chapter 6 for Toy tutorial specifically.
See: https://reviews.llvm.org/D94178
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D94651
|
| |
|
|
|
|
|
|
|
| |
This commit vAttachWait in lldb-server, so --waitfor can be used on
Linux
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D93895
|
| |
|
|
|
|
|
|
|
| |
Mirror ELF section parsing to support DWARF section names for
debug fission.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D93621
|
| |
|
|
|
|
|
|
|
|
| |
The way this test is structured right now, I set a breakpoint on
the instruction before the __builtin_trap. It hits the breakpoint,
disables the breakpoint, and instruction steps. This hits the
builtin_trap instruction which debugserver (on arm64) now advances
to the next instruction and reports that address to lldb. lldb
doesn't recognize this as a proper response to the instruction
step and continues executing until the next trap, and the test fails.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building with GCC 10, the following warning is reported:
```
/llvm-project/llvm/lib/Transforms/Coroutines/CoroFrame.cpp:1527:28: warning: unused variable ‘CS’ [-Wunused-variable]
1527 | if (CatchSwitchInst *CS =
```
This change adds a cast to `void` to avoid the warning.
Reviewed By: lxfind
Differential Revision: https://reviews.llvm.org/D94456
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-g is an IR generation option while -gsplit-dwarf is an object file generation option.
For -gsplit-dwarf in the backend phase of a distributed ThinLTO (-fthinlto-index=) which does object file generation and no IR generation, -g should not be needed.
This patch makes `-fthinlto-index= -gsplit-dwarf` emit .dwo even in the absence of -g.
This should fix https://crbug.com/1158215 after D80391.
```
// Distributed ThinLTO usage
clang -g -O2 -c -flto=thin -fthin-link-bitcode=a.indexing.o a.c
clang -g -O2 -c -flto=thin -fthin-link-bitcode=b.indexing.o b.c
clang -fuse-ld=lld -Wl,--thinlto-index-only=a.rsp -Wl,--thinlto-prefix-replace=';lto/' -Wl,--thinlto-object-suffix-replace='.indexing.o;.o' a.indexing.o b.indexing.o
clang -gsplit-dwarf -O2 -c -fthinlto-index=lto/a.o.thinlto.bc a.o -o lto/a.o
clang -gsplit-dwarf -O2 -c -fthinlto-index=lto/b.o.thinlto.bc b.o -o lto/b.o
clang -fuse-ld=lld @a.rsp -o exe
```
Note: for implicit regular/Thin LTO, .dwo emission works without this patch:
`clang -flto=thin -gsplit-dwarf a.o b.o` passes `-plugin-opt=dwo_dir=` to the linker.
The linker forwards the option to LTO. LTOBackend.cpp emits `$dwo_dir/[01234].dwo`.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D94647
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
For small enough, trivially copyable `T`, take the parameter by-value in
`SmallVector::resize`. Otherwise, when growing, update the arugment
appropriately.
Differential Revision: https://reviews.llvm.org/D93781
|
| |
|
|
|
|
| |
After 49142991a685bd427d7e877c29c77371dfb7634c, clang detects that MUL may be uninitialized. Set it to nullptr to suppress this check.
Adding an assert to check that it is ultimately set fails two test cases. Since this is not a new issue, leave the assertion commented out until a code owner can fix the bug. The two failing test cases are noted in the assertion comment.
|
| |
|
|
|
|
|
|
| |
For small enough, trivially copyable `T`, take the parameter by-value in
`SmallVector::append` and `SmallVector::insert`. Otherwise, when
growing, update the arugment appropriately.
Differential Revision: https://reviews.llvm.org/D93780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
single-element insert"
This reverts commit 56d1ffb927d03958a7a31442596df749264a7792, reapplying
9abac60309006db00eca0af406c2e16bef26807c, removing insert_one_maybe_copy
and using a helper called forward_value_param instead. This avoids use
of `std::is_same` (or any SFINAE), so I'm hoping it's more portable and
MSVC will be happier.
Original commit message follows:
For small enough, trivially copyable `T`, take the argument by value in
`SmallVector::push_back` and copy it when forwarding to
`SmallVector::insert_one_impl`. Otherwise, when growing, update the
argument appropriately.
Differential Revision: https://reviews.llvm.org/D93779
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
single-element insert"
This reverts commit 9abac60309006db00eca0af406c2e16bef26807c since there
are some bot errors on Windows:
http://lab.llvm.org:8011/#/builders/127/builds/4489
```
FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/IntervalMap.cpp.obj
C:\PROGRA~2\MIB055~1\2017\PROFES~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe /nologo /TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib\Support -IC:\b\slave\sanitizer-windows\llvm-project\llvm\lib\Support -Iinclude -IC:\b\slave\sanitizer-windows\llvm-project\llvm\include /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Zi /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2 -UNDEBUG -std:c++14 /EHs-c- /GR- /showIncludes /Folib\Support\CMakeFiles\LLVMSupport.dir\IntervalMap.cpp.obj /Fdlib\Support\CMakeFiles\LLVMSupport.dir\LLVMSupport.pdb /FS -c C:\b\slave\sanitizer-windows\llvm-project\llvm\lib\Support\IntervalMap.cpp
C:\b\slave\sanitizer-windows\llvm-project\llvm\include\llvm/ADT/SmallVector.h(746): error C2672: 'llvm::SmallVectorImpl<T>::insert_one_maybe_copy': no matching overloaded function found
with
[
T=llvm::IntervalMapImpl::Path::Entry
]
C:\b\slave\sanitizer-windows\llvm-project\llvm\include\llvm/ADT/SmallVector.h(745): note: while compiling class template member function 'llvm::IntervalMapImpl::Path::Entry *llvm::SmallVectorImpl<T>::insert(llvm::IntervalMapImpl::Path::Entry *,T &&)'
with
[
T=llvm::IntervalMapImpl::Path::Entry
]
C:\b\slave\sanitizer-windows\llvm-project\llvm\lib\Support\IntervalMap.cpp(22): note: see reference to function template instantiation 'llvm::IntervalMapImpl::Path::Entry *llvm::SmallVectorImpl<T>::insert(llvm::IntervalMapImpl::Path::Entry *,T &&)' being compiled
with
[
T=llvm::IntervalMapImpl::Path::Entry
]
C:\b\slave\sanitizer-windows\llvm-project\llvm\include\llvm/ADT/SmallVector.h(1136): note: see reference to class template instantiation 'llvm::SmallVectorImpl<T>' being compiled
with
[
T=llvm::IntervalMapImpl::Path::Entry
]
C:\b\slave\sanitizer-windows\llvm-project\llvm\include\llvm/ADT/IntervalMap.h(790): note: see reference to class template instantiation 'llvm::SmallVector<llvm::IntervalMapImpl::Path::Entry,4>' being compiled
C:\b\slave\sanitizer-windows\llvm-project\llvm\include\llvm/ADT/SmallVector.h(746): error C2783: 'llvm::IntervalMapImpl::Path::Entry *llvm::SmallVectorImpl<T>::insert_one_maybe_copy(llvm::IntervalMapImpl::Path::Entry *,ArgType &&)': could not deduce template argument for '__formal'
with
[
T=llvm::IntervalMapImpl::Path::Entry
]
C:\b\slave\sanitizer-windows\llvm-project\llvm\include\llvm/ADT/SmallVector.h(727): note: see declaration of 'llvm::SmallVectorImpl<T>::insert_one_maybe_copy'
with
[
T=llvm::IntervalMapImpl::Path::Entry
]
```
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
insert
For small enough, trivially copyable `T`, take the argument by value in
`SmallVector::push_back` and copy it when forwarding to
`SmallVector::insert_one_impl`. Otherwise, when growing, update the
argument appropriately.
Differential Revision: https://reviews.llvm.org/D93779
|
| |
|
|
| |
This reverts commit 336ab2d51dfdd5ca09c2a9c506453db4fe653584.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The patch tries to fold sqrt/sdiv test node, i.g FTSQRT, XVTDIVDP, and the branch, i.e br_cc if they meet these patterns:
(br_cc seteq, (truncateToi1 SWTestOp), 0) -> (BCC PRED_NU, SWTestOp)
(br_cc seteq, (and SWTestOp, 2), 0) -> (BCC PRED_NE, SWTestOp)
(br_cc seteq, (and SWTestOp, 4), 0) -> (BCC PRED_LE, SWTestOp)
(br_cc seteq, (and SWTestOp, 8), 0) -> (BCC PRED_GE, SWTestOp)
(br_cc setne, (truncateToi1 SWTestOp), 0) -> (BCC PRED_UN, SWTestOp)
(br_cc setne, (and SWTestOp, 2), 0) -> (BCC PRED_EQ, SWTestOp)
(br_cc setne, (and SWTestOp, 4), 0) -> (BCC PRED_GT, SWTestOp)
(br_cc setne, (and SWTestOp, 8), 0) -> (BCC PRED_LT, SWTestOp)
Reviewed By: steven.zhang
Differential Revision: https://reviews.llvm.org/D94054
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The number of hardware threads available to a ThreadPool can be limited if setting an affinity mask.
For example:
> start /B /AFFINITY 0xF lld-link.exe ...
Would let LLD only use 4 hyper-threads.
Previously, there was an outstanding issue on Windows Server 2019 on dual-CPU machines, which was preventing from using both CPU sockets. In normal conditions, when no affinity mask was set, ProcessorGroup::AllThreads was different from ProcessorGroup::UsableThreads. The previous code in llvm/lib/Support/Windows/Threading.inc L201 was improperly assuming those two values to be equal, and consequently was limiting the execution to only one CPU socket.
Differential Revision: https://reviews.llvm.org/D92419
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch custom lowers ISD::VSCALE into a csrr vlenb followed
by a shift right by 3 followed by a multiply by the scale amount.
I've added computeKnownBits support to indicate that the csrr vlenb
always produces 3 trailng bits of 0s so the shift right is "exact".
This allows the shift and multiply sequence to be nicely optimized
into a single shift or removed completely when the scale amount is
a power of 2.
The non power of 2 case multiplying by 24 is still producing
suboptimal code. We could remove the right shift and use a
multiply by 3. Hopefully we can improve DAG combine to fix that
since it's not unique to this sequence.
This replaces D94144.
Reviewed By: HsiangKai
Differential Revision: https://reviews.llvm.org/D94249
|
| |
|
|
|
|
|
|
|
|
| |
It's possible to declare an external procedure and then pass it as an
actual argument to a subprogram expecting a procedure argument. I added
tests for this and added an error message to distinguish passing an
actual argument with an implicit interface from passing an argument with
a mismatched explicit interface.
Differential Revision: https://reviews.llvm.org/D94505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An AArch64 sigreturn trampoline frame can't currently be described
in a DWARF .eh_frame section, because the AArch64 DWARF spec currently
doesn't define a constant for the PC register. (PC and LR may need to
be restored to different values.)
Instead, use the same technique as libgcc or github.com/libunwind and
detect the sigreturn frame by looking for the sigreturn instructions:
mov x8, #0x8b
svc #0x0
If a sigreturn frame is detected, libunwind restores all the GPRs by
assuming that sp points at an rt_sigframe Linux kernel struct. This
behavior is a fallback mode that is only used if there is no ordinary
unwind info for sigreturn.
If libunwind can't find unwind info for a PC, it assumes that the PC is
readable, and would crash if it isn't. This could happen if:
- The PC points at a function compiled without unwind info, and which
is part of an execute-only mapping (e.g. using -Wl,--execute-only).
- The PC is invalid and happens to point to unreadable or unmapped
memory.
In the tests, ignore a failed dladdr call so that the tests can run on
user-mode qemu for AArch64, which uses a stack-allocated trampoline
instead of a vDSO.
Reviewed By: danielkiss, compnerd, #libunwind
Differential Revision: https://reviews.llvm.org/D90898
|
| |
|
|
|
|
|
|
|
|
| |
This needs to be done in order to not crash with -misched-cutoff.
Fixes https://bugs.llvm.org/show_bug.cgi?id=45928
Review: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D94383
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
to Pass.h.
In some compiler passes like SampleProfileLoaderPass, we want to know which
LTO/ThinLTO phase the pass is in. Currently the phase is represented in enum
class PassBuilder::ThinLTOPhase, so it is only available in PassBuilder and
it also cannot represent phase in full LTO. The patch extends it to include
full LTO phases and move it from PassBuilder.h to Pass.h, then it is much
easier for PassBuilder to communiate with each pass about current LTO phase.
Differential Revision: https://reviews.llvm.org/D94613
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current code breaks this version of MSVC due to a mismatch between `std::is_trivially_copyable` and `llvm::is_trivially_copyable` for `std::pair` instantiations. Hence I was attempting to use `std::is_trivially_copyable` to set `llvm::is_trivially_copyable<T>::value`.
I spent some time root causing an `llvm::Optional` build error on MSVC 16.8.3 related to the change described above:
```
62>C:\src\ocg_llvm\llvm-project\llvm\include\llvm/ADT/BreadthFirstIterator.h(96,12): error C2280: 'llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>>::operator =(const llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &)': attempting to reference a deleted function (compiling source file C:\src\ocg_llvm\llvm-project\llvm\unittests\ADT\BreadthFirstIteratorTest.cpp)
...
```
The "trivial" specialization of `optional_detail::OptionalStorage` assumes that the value type is trivially copy constructible and trivially copy assignable. The specialization is invoked based on a check of `is_trivially_copyable` alone, which does not imply both `is_trivially_copy_assignable` and `is_trivially_copy_constructible` are true.
[[ https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable | According to the spec ]], a deleted assignment operator does not make `is_trivially_copyable` false. So I think all these properties need to be checked explicitly in order to specialize `OptionalStorage` to the "trivial" version:
```
/// Storage for any type.
template <typename T, bool = std::is_trivially_copy_constructible<T>::value
&& std::is_trivially_copy_assignable<T>::value>
class OptionalStorage {
```
Above fixed my build break in MSVC, but I think we need to explicitly check `is_trivially_copy_constructible` too since it might be possible the copy constructor is deleted. Also would be ideal to move over to `std::is_trivially_copyable` instead of the `llvm` namespace verson.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D93510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generated code for the split fp128 load/stores was missing a small yet important adjustment to the pointer metadata being fed into `getStore` and `getLoad`, making it out of sync with the effective memory address.
This problem often resulted in instructions being scheduled in the wrong order.
I also took this chance to clean up some "wrong" uses of `getAlignment` as done in D77687.
Thanks @jrtc27 for finding the problem and providing a patch.
Patch by LemonBoy and Jessica Clarke(jrtc27)
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D94345
|
| |
|
|
|
|
|
|
| |
This matches the legacy pipeline/pass.
Reviewed By: asbirlea, SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D94559
|
| |
|
|
|
| |
This reverts commit e0963ae274be5b071d1e1b00f5e4e019483c09e9. The change
breaks some GDB tests. Revert it while we investigate.
|
| | |
|
| |
|
|
|
|
|
|
| |
There is currently a driver test but no test for its effect on linkageName & pass pipeline.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D94381
|
| |
|
|
|
|
|
|
|
|
| |
isblank and iscntrl were casting an int to a char implicitly and this
was throwing errors under Fuchsia. I've added a static cast to resolve
this issue.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D94634
|
| |
|
|
|
|
| |
This patch pre-commits test cases with dead stores of
existing values for D90328. It also updates a few tests that had such
stores by accident, to preserve the original spirit of those tests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves utils/UnitTest/Test.[h/cpp] to LibcTest.[h/cpp] and adds a
new Test.h that acts as a switcher so that Fuchsia can use the zxtest
backend for running our tests as part of their build.
FuchsiaTest.h is for including fuchsia's zxtest library and anything
else needed to make the tests work under fuchsia (currently just
undefining the isascii macro for the test).
Downstream users, please fix your build instead of reverting.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D94625
|
| |
|
|
|
|
|
|
| |
If a module specifies default private accessibility, names that have
been use-associated are private by default. This was not reflected in
.mod files.
Differential Revision: https://reviews.llvm.org/D94602
|
| |
|
|
|
| |
This patch adds a test for the -lto-freestanding option, similar to
llvm/test/ThinLTO/X86/tli-nobuiltin.ll.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to the parallelization strategies, the vectorization strategies
provide control on what loops should be vectorize. Unlike the parallel
strategies, only innermost loops are considered, but including reductions,
with the control of vectorizing dense loops only or dense and sparse loops.
The vectorized loops are always controlled by a vector mask to avoid
overrunning the iterations, but subsequent vector operation folding removes
redundant masks and replaces the operations with more efficient counterparts.
Similarly, we will rely on subsequent loop optimizations to further optimize
masking, e.g. using an unconditional full vector loop and scalar cleanup loop.
The current strategy already demonstrates a nice interaction between the
sparse compiler and all prior optimizations that went into the vector dialect.
Ongoing discussion at:
https://llvm.discourse.group/t/mlir-support-for-sparse-tensors/2020/10
Reviewed By: penpornk
Differential Revision: https://reviews.llvm.org/D94551
|
| |
|
|
|
|
|
|
| |
Split out from D91250. Fixes wrong ssa_copy naming.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D94310
|
| |
|
|
|
|
| |
Consistently saves approx. 0.6 sec (out of 18 sec) on a large output (400 MB EXE, 2 GB PDB).
Differential Revision: https://reviews.llvm.org/D94555
|
| |
|
|
|
|
|
| |
This corrects the last 2 issues caught by tests when causing dialect
conversion rollbacks to occur.
Differential Revision: https://reviews.llvm.org/D94623
|
| | |
|
