Louis Dionne [Tue, 15 Jun 2021 20:08:38 +0000 (16:08 -0400)]
[libc++] Undeprecate the std::allocator<void> specialization
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.
As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.
Fixes http://llvm.org/PR50299
Differential Revision: https://reviews.llvm.org/D104323
Andrea Di Biagio [Wed, 16 Jun 2021 13:39:14 +0000 (14:39 +0100)]
[MCA][InstrBuilder] Always check for implicit uses of resource units (PR50725).
When instructions are issued to the underlying pipeline resources, the
mca::ResourceManager should also check for the presence of extra uses induced by
the explicit consumption of multiple partially overlapping group resources.
Fixes PR50725
Nicolas Vasilache [Wed, 16 Jun 2021 11:10:00 +0000 (11:10 +0000)]
[mlir] NFC - Drop newline form BlockArgument printing.
Differential Revision: https://reviews.llvm.org/D104368
Simon Pilgrim [Wed, 16 Jun 2021 12:42:11 +0000 (13:42 +0100)]
[X86][AVX] Regenerate pr15296.ll tests
Exposes some really bad shift lowering codegen in shiftInput___canonical
Ben Dunbobbin [Fri, 11 Jun 2021 12:35:04 +0000 (13:35 +0100)]
[llvm-symbolizer] improve test and fix doc example after recent --print-source-context-lines behaviour change
I believe that after https://reviews.llvm.org/D102355 the behaviour of --print-source-context-lines has changed.
Before: --print-source-context-lines=3 prints 4 lines.
After: --print-source-context-lines=3 prints 3 lines.
Adjust the example in the docs for this change and make the testing a little more robust.
Differential Revision: https://reviews.llvm.org/D104114
Jay Foad [Wed, 16 Jun 2021 12:35:29 +0000 (13:35 +0100)]
[AMDGPU] Set SALU, VALU and other instruction type flags on Real instructions
This does not affect codegen but might benefit llvm-mca.
Amilendra Kodithuwakku [Wed, 16 Jun 2021 12:18:01 +0000 (13:18 +0100)]
[libcxx] Fix exception raised during downstream bare-metal libunwind tests
Fix for the following exception.
AttributeError: 'TestingConfig' object has no attribute 'target_triple'
Related revision: https://reviews.llvm.org/D102012
'TestingConfig' object has no attribute 'target_triple'
Reviewed By: #libunwind, miyuki, danielkiss, mstorsjo
Differential Revision: https://reviews.llvm.org/D103140
Guillaume Chatelet [Tue, 15 Jun 2021 07:57:13 +0000 (07:57 +0000)]
[libc] Add a set of elementary operations
Resubmission of D100646 now making sure that we handle cases were `__builtin_memcpy_inline` is not available.
Original commit message:
Each of these elementary operations can be assembled to support higher order constructs (Overlapping access, Loop, Aligned Loop).
The patch does not compile yet as it depends on other ones (D100571, D100631) but it allows to get the conversation started.
A self-contained version of this code is available at https://godbolt.org/z/e1x6xdaxM
Dylan Fleming [Wed, 16 Jun 2021 12:01:58 +0000 (13:01 +0100)]
[SVE] Fix PromoteIntRes_TRUNCATE not to call getVectorNumElements
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D104115
Raphael Isemann [Wed, 16 Jun 2021 12:04:31 +0000 (14:04 +0200)]
[lldb] Require Clang 8 for gpubnames test
This test is using -gpubnames which is only available since Clang 8. The
original Clang 7 requirement was based on the availability of
-accel-tables=Dwarf (which the test initially used before being changed to
-gpubnames in commit
15a6df52efaa7 ).
AndreyChurbanov [Wed, 16 Jun 2021 11:47:29 +0000 (14:47 +0300)]
[OpenMP] libomp: fixed implementation of OMP 5.1 inoutset task dependence type
Refactored code of dependence processing and added new inoutset dependence type.
Compiler can set dependence flag to 0x8 when call __kmpc_omp_task_with_deps.
All dependence flags library gets so far and corresponding dependence types:
1 - IN, 2 - OUT, 3 - INOUT, 4 - MUTEXINOUTSET, 8 - INOUTSET.
Differential Revision: https://reviews.llvm.org/D97085
Diana Picus [Wed, 16 Jun 2021 11:11:35 +0000 (11:11 +0000)]
[flang] Check there's no dependency on C++ libs. NFC
Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.
This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).
This is a recommit of 7ddbf26, with 2 fixes:
* Replace C++ comments with C comments
* Only enable the test if libFortranRuntime.a exists (this might not be
the case if e.g. BUILD_SHARED_LIBS=On)
Differential Revision: https://reviews.llvm.org/D104290
Jay Foad [Wed, 16 Jun 2021 11:16:21 +0000 (12:16 +0100)]
[AMDGPU] Set IsAtomicRet and IsAtomicNoRet on Real instructions
This does not affect codegen but might benefit llvm-mca.
Guillaume Chatelet [Wed, 16 Jun 2021 11:22:46 +0000 (11:22 +0000)]
Revert "[libc] Add a set of elementary operations"
This reverts commit
4694321fbe54628513b75a4395124cd7508581a6.
Guillaume Chatelet [Tue, 15 Jun 2021 07:57:13 +0000 (07:57 +0000)]
[libc] Add a set of elementary operations
Resubmission of D100646 now making sure that we handle cases were `__builtin_memcpy_inline` is not available.
Original commit message:
Each of these elementary operations can be assembled to support higher order constructs (Overlapping access, Loop, Aligned Loop).
The patch does not compile yet as it depends on other ones (D100571, D100631) but it allows to get the conversation started.
A self-contained version of this code is available at https://godbolt.org/z/e1x6xdaxM
Raphael Isemann [Wed, 16 Jun 2021 11:02:18 +0000 (13:02 +0200)]
[lldb] vwprintw -> vw_printw in IOHandlerCursesGUI
`vwprintw` is (in theory) using the `arargs.h` va_list while `vw_printw` is
using the `stdarg.h` va_list. It seems these days they can be used
interchangeably but `vwprintw` is marked as deprecated.
Jay Foad [Wed, 16 Jun 2021 11:00:37 +0000 (12:00 +0100)]
[AMDGPU] Set mayLoad and mayStore on Real instructions
This does not affect codegen but might benefit llvm-mca.
Diana Picus [Wed, 16 Jun 2021 11:08:42 +0000 (11:08 +0000)]
Revert "[flang] Check there's no dependency on C++ libs"
This reverts commit
7ddbf2633911a5c378ad6af01e250f6f252b9032.
This doesn't work if we're not building libFortranRuntime.a. I'll
recommit with a fix.
Nico Weber [Wed, 16 Jun 2021 01:38:29 +0000 (21:38 -0400)]
[lld/mac] Add support for -no_data_in_code_info flag
Differential Revision: https://reviews.llvm.org/D104345
Nico Weber [Wed, 16 Jun 2021 10:38:13 +0000 (06:38 -0400)]
[lld/mac] Put lld-only flags in "LLD-SPECIFIC:" --help section
Differential Revision: https://reviews.llvm.org/D104347
Konstantin Schwarz [Mon, 7 Jun 2021 10:40:44 +0000 (12:40 +0200)]
[ELF] Consider that NOLOAD sections should be placed in a PT_LOAD segment
During PHDR creation, the case where an output section does not require a
PT_LOAD header but still occupies memory in the current VMA region was not handled.
If such an output section interleaves two output sections that have the same
VMA and LMA regions set, we would previously re-use the existing PT_LOAD header
for the second output section.
However, since the memory region is not contiguous, we need to start a new PT_LOAD
segment.
This fixes https://bugs.llvm.org/show_bug.cgi?id=50558
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D103815
Alex Zinenko [Wed, 16 Jun 2021 10:12:36 +0000 (12:12 +0200)]
[mlir] ODS: temporarily disbale external model in presence of extra class declarations
Default implementations of interfaces may rely on extra class
declarations, which aren't currently generated in the external model,
that in turn may rely on functions defined in the main Attribute/Type
class, which wouldn't be available on the external model.
David Green [Wed, 16 Jun 2021 10:11:03 +0000 (11:11 +0100)]
[ARM] Correct type of setcc results for FP vectors
Under MVE v4f32 and v8f16 vectors should be using v4i1/v8i1 predicates
for the setcc result type, as they have predicated registers for those
types. Setting this correctly prevents some inefficient optimizations
from happening.
David Green [Wed, 16 Jun 2021 09:49:50 +0000 (10:49 +0100)]
[ARM] Extra tests for sign extended floating point compares. NFC
Diana Picus [Wed, 16 Jun 2021 09:41:11 +0000 (09:41 +0000)]
[flang] Fixup
7ddbf2633911a5c378ad6af01e250f6f252b9032
Replace C++ comments with C-style comments (not sure why my C compiler
doesn't complain about this).
Sjoerd Meijer [Wed, 16 Jun 2021 09:31:32 +0000 (10:31 +0100)]
[FuncSpec] Remove other passes in a test RUN line. NFC.
Diana Picus [Fri, 11 Jun 2021 09:07:23 +0000 (09:07 +0000)]
[flang] Add clang-tidy check for braces around if
Flang diverges from the llvm coding style in that it requires braces
around the bodies of if/while/etc statements, even when the body is
a single statement.
This commit adds the readability-braces-around-statements check to
flang's clang-tidy config file. Hopefully the premerge bots will pick it
up and report violations in Phabricator.
We also explicitly disable the check in the directories corresponding to
the Lower and Optimizer libraries, which rely heavily on mlir and llvm
and therefore follow their coding style. Likewise for the tools
directory.
We also fix any outstanding violations in the runtime and in
lib/Semantics.
Differential Revision: https://reviews.llvm.org/D104100
Sjoerd Meijer [Wed, 16 Jun 2021 09:05:39 +0000 (10:05 +0100)]
[FuncSpec] Add test for a call site that will never be executed. NFC.
James Henderson [Thu, 10 Jun 2021 14:33:41 +0000 (15:33 +0100)]
[yaml2obj][obj2yaml] Support custom ELF section header string table name
This patch adds support for a new field in the FileHeader, which states
the name to use for the section header string table. This also allows
combining the string table with another string table in the object, e.g.
the symbol name string table. The field is optional. By default,
.shstrtab will continue to be used.
This partially fixes https://bugs.llvm.org/show_bug.cgi?id=50506.
Reviewed by: Higuoxing
Differential Revision: https://reviews.llvm.org/D104035
James Henderson [Fri, 11 Jun 2021 08:43:24 +0000 (09:43 +0100)]
[yaml2obj] Fix bug when referencing items in SectionHeaderTable
There was an off-by-one error caused by an index (which included an
index for the null section header) being used to check against the size
of a list of sections (which didn't include the null section header).
This is a partial fix for https://bugs.llvm.org/show_bug.cgi?id=50506.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D104098
Jay Foad [Tue, 15 Jun 2021 12:15:42 +0000 (13:15 +0100)]
[AMDGPU] Set more flags on Real instructions
This does not affect codegen, which only tests these flags on Pseudo
instructions, but might help llvm-mca which has to work with Real
instructions. In particular setting LGKM_CNT on DS instructions helps
with the problem identified in D104149.
Differential Revision: https://reviews.llvm.org/D104293
Diana Picus [Mon, 14 Jun 2021 13:25:16 +0000 (13:25 +0000)]
[flang] Check there's no dependency on C++ libs
Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.
This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).
Differential Revision: https://reviews.llvm.org/D104290
Jay Foad [Tue, 15 Jun 2021 16:19:43 +0000 (17:19 +0100)]
[AMDGPU] Use defvar in SOPInstructions.td. NFC.
Factor out repeated !cast<SOP*_Pseudo>(NAME) into a new "defvar ps",
just to improve readability and maintainability.
Differential Revision: https://reviews.llvm.org/D104306
Joachim Protze [Wed, 16 Jun 2021 08:11:10 +0000 (10:11 +0200)]
[OpenMP][NFC] Add back suppression of warning
Commit
cff215565e9 did not fix all unused variables in different builds,
so adding back the suppression for now.
Sjoerd Meijer [Fri, 11 Jun 2021 14:03:07 +0000 (15:03 +0100)]
[FuncSpec] Statistics
Adds some bookkeeping for collecting the number of specialised functions and a
test for that.
Differential Revision: https://reviews.llvm.org/D104102
Lang Hames [Wed, 16 Jun 2021 05:12:12 +0000 (15:12 +1000)]
[ORC] Switch to WrapperFunction utility for calls to registration functions.
Addresses FIXMEs in TPC-based EH-frame and debug object registration code by
replacing manual argument serialization with WrapperFunction utility calls.
Andrzej Warzynski [Wed, 16 Jun 2021 08:00:50 +0000 (08:00 +0000)]
[flang][nfc] Move `external-hello-world` to flang/examples
As `external-hello-world` is not really a test, I am moving it from
`flang/unittest/Runtime` to `flang/examples` (it makes a lot of sense as
an example). I've not modified the source code (apart from adjusting the
include paths).
Differential Revision: https://reviews.llvm.org/D104320
Andrzej Warzynski [Tue, 15 Jun 2021 15:30:23 +0000 (15:30 +0000)]
[flang][driver] Add `-fdebug-dump-all`
The new option will run the semantic checks and then dump the parse tree
and all the symbols. This is equivalent to running the driver twice,
once with `-fdebug-dump-parse-tree` and then with
the `-fdebug-dump-symbols` action flag.
Currently we wouldn't be able to achieve the same by simply running:
```
flang-new -fc1 -fdebug-dump-parse-tree -fdebug-dump-symbols <input-file>
```
That's because the new driver will only run one frontend action per
invocation (both of the flags used here are action flags). Diverging
from this design would lead to costly compromises and it's best avoided.
We may want to consider re-designing our debugging actions (and action
options) in the future so that there's more code re-use. For now, I'm
focusing on making sure that we support all the major cases requested by
our users.
Differential Revision: https://reviews.llvm.org/D104305
Joachim Protze [Tue, 15 Jun 2021 07:17:26 +0000 (09:17 +0200)]
[OpenMP] Remove unused variables from libomp code
Several variables were left unused as a result of different patches removing
their use.
Two variables have some use:
`poll_count` is used by the KMP_BLOCKING macro only under certain conditions.
Adding (void) to tell the compiler to ignore the unused variable.
`padding` is a dummy stack allocation with no intent to be used. Also adding
(void) to make the compiler ignore the unused variable.
Differential Revision: https://reviews.llvm.org/D104303
Roman Lebedev [Wed, 16 Jun 2021 07:24:33 +0000 (10:24 +0300)]
[NFC][X86] lowerVECTOR_SHUFFLE(): drop FIXME about widening to i128 (YMM half) element type
As per the discussion in D103818, so far, this does not appear to be worthwhile.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D103818
Roman Lebedev [Wed, 16 Jun 2021 07:24:25 +0000 (10:24 +0300)]
[SCEV] PtrToInt on non-integral pointers is allowed
As per (committed without review) @reames's rGac81cb7e6dde9b0890ee1780eae94ab96743569b change,
we are now allowed to produce `ptrtoint` for non-integral pointers.
This will unblock further unbreaking of SCEV regarding int-vs-pointer type confusion.
Reviewed By: mkazantsev
Differential Revision: https://reviews.llvm.org/D104322
Evgeniy Brevnov [Wed, 9 Jun 2021 11:24:02 +0000 (18:24 +0700)]
[SLP] Incorrect handling of external scalar values
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D103954
Andrew Browne [Wed, 16 Jun 2021 01:51:25 +0000 (18:51 -0700)]
[DFSan][NFC] Fix shadowing variable name.
Chen Zheng [Wed, 16 Jun 2021 05:03:06 +0000 (05:03 +0000)]
[LLDB] Fix buildbots breakage due to TestGuessLanguage.py
Fix LLDB buidbot breakage due to D104291
Differential Revision: https://reviews.llvm.org/D104291
Rong Xu [Wed, 16 Jun 2021 04:31:27 +0000 (21:31 -0700)]
[SampleFDO] Place the discriminator flag variable into the used list.
We create flag variable "__llvm_fs_discriminator__" in the binary
to indicate that FSAFDO hierarchical discriminators are used.
This variable might be GC'ed by the linker since it is not explicitly
reference. I initially added the var to the use list in pass
MIRFSDiscriminator but it did not work. It turned out the used global
list is collected in lowering (before MIR pass) and then emitted in
the end of pass pipeline.
Here I add the variable to the use list in IR level's AddDiscriminators
pass. The machine level code is still keep in the case IR's
AddDiscriminators is not invoked. If this is the case, this just use
-Wl,--export-dynamic-symbol=__llvm_fs_discriminator__
to force the emit.
Differential Revision: https://reviews.llvm.org/D103988
Peter Steinfeld [Tue, 15 Jun 2021 20:09:12 +0000 (13:09 -0700)]
[flang] Add semantic check for the RANDOM_SEED intrinsic
I added the only check that wasn't already tested along with tests for
many valid and invalid arguments.
Differential Revision: https://reviews.llvm.org/D104318
Rong Xu [Wed, 16 Jun 2021 04:22:23 +0000 (21:22 -0700)]
Revert "[SampleFDO] Using common linkage for the discriminator flag variable"
This reverts commit
434fed5aff5e62460e2e984c7cc2674c12779b1e.
Post commit review suggested to use another implmenentation.
Detailed can be found in the review.
Fangrui Song [Wed, 16 Jun 2021 03:32:24 +0000 (20:32 -0700)]
[Driver] Delete -fsanitize-coverage-blocklist= in favor of -fsanitize-coverage-ignorelist=
We are settled with -fsanitize-coverage-ignorelist (D101832).
Just delete -fsanitize-coverage-blocklist which is also new.
Chen Zheng [Tue, 15 Jun 2021 11:10:07 +0000 (11:10 +0000)]
[Debug-Info] guard DW_LANG_C_plus_plus_14 under strict dwarf
Reviewed By: stuart
Differential Revision: https://reviews.llvm.org/D104291
Saleem Abdulrasool [Mon, 14 Jun 2021 00:39:19 +0000 (17:39 -0700)]
X86: balance the frame prologue and epilogue on Win64
This was broken in
ba1509da7b89c850c89f0f98afbab375794cd3c8. The Win64
frame would not perform the setup of the Swift async context parameter
but would tear down the setup in the epilogue resulting in crashes.
This ensures that we do the full setup when we do the tear down.
Although this is non-conforming to the Win64 calling convention, it
corrects the setup and exposes the actual issue that the change
introduced: incorrect frame setup.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D104246
Chuanqi Xu [Tue, 15 Jun 2021 02:55:38 +0000 (10:55 +0800)]
[FuncSpec] Use std::pow instead of operator^
The original implementation calculating UserBonus uses operator ^, which means XOR in C++
language.
At the first glance of reviewing, I thought it should be power, my bad.
It doesn't make sense to use XOR here. So I believe it should be a
carelessness as I made.
Test Plan: check-all
Reviewed By: SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D104282
Kevin Athey [Wed, 16 Jun 2021 01:26:31 +0000 (18:26 -0700)]
[NFC][sanitizer] Remove calls to __asan_get_current_fake_stack
Unnecessary with -fsanitize-address-use-after-return=never.
for issue: https://github.com/google/sanitizers/issues/1394
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D104154
Andrew Browne [Mon, 14 Jun 2021 20:41:24 +0000 (13:41 -0700)]
[DFSan] Handle landingpad inst explicitly as zero shadow.
Before this change, DFSan was relying fallback cases when getting origin
address.
Differential Revision: https://reviews.llvm.org/D104266
Louis Dionne [Tue, 15 Jun 2021 19:07:03 +0000 (15:07 -0400)]
[libc++] Promote GCC 11 to mandatory CI
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
Jim Ingham [Tue, 15 Jun 2021 23:35:44 +0000 (16:35 -0700)]
Don't depend on the "run" alias doing shell expanding.
Instead dial it up explicitly.
This test started failing recently and I'm not sure why. It also
doesn't make sense to me the replacing "run" with "process launch -X 1 --"
should make any difference - run is an alias for the latter. But
it does pass with the change, and unless we are testing for the exact
run alias, it's better to ask for what we want explicitly.
Wenlei He [Tue, 15 Jun 2021 22:50:52 +0000 (15:50 -0700)]
CMake: allow overriding CMAKE_CXX_VISIBILITY_PRESET
This allows overriding the `CMAKE_CXX_VISIBILITY_PRESET` on the command line. For example, setting the value to `default` lets PIC LLVM static libraries be converted to DSOs, without the need to rebuild LLVM with BUILD_SHARED_LIBS=ON.
Reviewed By: wenlei
Differential Revision: https://reviews.llvm.org/D104168
Aart Bik [Tue, 15 Jun 2021 02:07:03 +0000 (19:07 -0700)]
[mlir][sparse] integration test for all-dense annotated "sparse" output
Reviewed By: gussmith23
Differential Revision: https://reviews.llvm.org/D104277
Jim Ingham [Tue, 15 Jun 2021 22:42:50 +0000 (15:42 -0700)]
Missed a Windows use of ValidForThisThread in the changes for
cfb96d845a684a5c567823dbe2aa4392937ee979.
Fangrui Song [Tue, 15 Jun 2021 22:22:07 +0000 (15:22 -0700)]
[docs] Exclude FlangOption and re-generate ClangCommandLineReference.rst
MaheshRavishankar [Tue, 15 Jun 2021 21:15:40 +0000 (14:15 -0700)]
[mlir][SCF] Remove empty else blocks of `scf.if` operations.
Differential Revision: https://reviews.llvm.org/D104273
Zequan Wu [Tue, 15 Jun 2021 21:43:39 +0000 (14:43 -0700)]
[OpaquePtr] Verify Opaque pointer in function parameter
Verifying opaque pointer as function parameter when using with `byval`, `byref`,
`inalloca`, `preallocated`.
Differential Revision: https://reviews.llvm.org/D104309
Aart Bik [Fri, 11 Jun 2021 17:33:43 +0000 (10:33 -0700)]
[mlir][sparse] allow all-dense annotated "sparse" tensor output
This is a very careful start with alllowing sparse tensors at the
left-hand-side of tensor index expressions (viz. sparse output).
Note that there is a subtle difference between non-annotated tensors
(dense, remain n-dim, handled by classic bufferization) and all-dense
annotated "sparse" tensors (linearized to 1-dim without overhead
storage, bufferized by sparse compiler, backed by runtime support library).
This revision gently introduces some new IR to facilitate annotated outputs,
to be generalized to truly sparse tensors in the future.
Reviewed By: gussmith23, bixia
Differential Revision: https://reviews.llvm.org/D104074
Rong Xu [Tue, 15 Jun 2021 19:32:03 +0000 (12:32 -0700)]
[SampleFDO] Using common linkage for the discriminator flag variable
We create flag variable "__llvm_fs_discriminator__" in the binary
to indicate that FSAFDO hierarchical discriminators are used.
This variable might be GC'ed by the linker since it is not explicitly
reference. I initially added the var to the use list in pass
MIRFSDiscriminator but it did not work. It turned out the used global
list is collected in lowering (before MIR pass) and then emitted in
the end of pass pipeline.
In this patch, we use a "common" linkage for this variable so that
it will be GC'ed by the linker.
Differential Revision: https://reviews.llvm.org/D103988
Jim Ingham [Sat, 12 Jun 2021 00:00:46 +0000 (17:00 -0700)]
Convert functions that were returning BreakpointOption * to BreakpointOption &.
This is an NFC cleanup.
Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers & unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.
This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.
It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP. Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.
Differential Revision: https://reviews.llvm.org/D104162
Peyton, Jonathan L [Thu, 3 Jun 2021 19:09:09 +0000 (14:09 -0500)]
[OpenMP] Add GOMP 5.0 version symbols to API
* Add GOMP versioned pause functions
* Add GOMP versioned affinity format functions
To do the affinity format functions, only attach versioned symbols
to the APPEND Fortran entries (e.g., omp_set_affinity_format_) since
GOMP only exports two symbols (one for Fortran, one for C). Our
affinity format functions have three symbols.
e.g., with omp_set_affinity_format:
1) omp_set_affinity_format (Fortran interface)
2) omp_set_affinity_format_ (Fortran interface)
3) ompc_set_affinity_format (C interface)
Have the GOMP version of the C symbol alias the ompc_* 3) version
instead of the Fortran unappended version 1).
Differential Revision: https://reviews.llvm.org/D103647
Peyton, Jonathan L [Thu, 3 Jun 2021 17:49:04 +0000 (12:49 -0500)]
[OpenMP] Fix affinity determine capable algorithm on Linux
Remove strange checks for syscall() arguments where mask is NULL.
Valgrind reports these as error usages for the syscall.
Instead, just check if CACHE_LINE bytes is long enough. If not, then
search for the size. Also, by limiting the first size detection
attempt to CACHE_LINE bytes, instead of 1MB, we don't use more than one
cache line for the mask size. Before this patch, sometimes the returned
mask size was 640 bytes (10 cache lines) because the initial call to
getaffinity() was limited only by the internal kernel mask size
which can be very large.
Differential Revision: https://reviews.llvm.org/D103637
Peyton, Jonathan L [Wed, 2 Jun 2021 15:39:40 +0000 (10:39 -0500)]
[OpenMP] Lazily assign root affinity
Lazily set affinity for root threads. Previously, the root thread
executing middle initialization would attempt to assign affinity
to other existing root threads. This was not working properly as the
set_system_affinity() function wasn't setting the affinity for the
target thread. Instead, the middle init thread was resetting the
its own affinity using the target thread's affinity mask.
Differential Revision: https://reviews.llvm.org/D103625
Muhammad Omair Javaid [Tue, 15 Jun 2021 10:41:38 +0000 (15:41 +0500)]
AArch64 Linux and elf-core PAC stack unwinder support
This patch builds on D100521 and other related patches to add support
for unwinding stack on AArch64 systems with pointer authentication
feature enabled.
We override FixCodeAddress and FixDataAddress function in ABISysV_arm64
class. We now try to calculate and set code and data masks after reading
data_mask and code_mask registers exposed by AArch64 targets running Linux.
This patch utilizes core file linux-aarch64-pac.core for testing that
LLDB can successfully unwind stack frames in the presence of signed
return address after masking off ignored bits.
This patch also includes a AArch64 Linux native test case to demonstrate
successful back trace calculation in presence of pointer authentication
feature.
Differential Revision: https://reviews.llvm.org/D99944
Siva Chandra Reddy [Tue, 15 Jun 2021 20:57:51 +0000 (20:57 +0000)]
[libc][NFC] Disable thrd_test as it is exhibiting flaky behavior on the bots.
Andrea Di Biagio [Tue, 15 Jun 2021 20:34:41 +0000 (21:34 +0100)]
Revert "[MCA] Adding the CustomBehaviour class to llvm-mca"
This reverts commit
f7a23ecece524564a0c3e09787142cc6061027bb.
It appears to breaks buildbots that don't build the AMDGPU backend.
Patrick Holland [Tue, 15 Jun 2021 20:20:35 +0000 (21:20 +0100)]
[MCA] Adding the CustomBehaviour class to llvm-mca
Some instructions are not defined well enough within the target’s scheduling
model for llvm-mca to be able to properly simulate its behaviour. The ideal
solution to this situation is to modify the scheduling model, but that’s not
always a viable strategy. Maybe other parts of the backend depend on that
instruction being modelled the way that it is. Or maybe the instruction is quite
complex and it’s difficult to fully capture its behaviour with tablegen. The
CustomBehaviour class (which I will refer to as CB frequently) is designed to
provide intuitive scaffolding for developers to implement the correct modelling
for these instructions.
Implementation details:
llvm-mca does its best to extract relevant register, resource, and memory
information from every MCInst when lowering them to an mca::Instruction. It then
uses this information to detect dependencies and simulate stalls within the
pipeline. For some instructions, the information that gets captured within the
mca::Instruction is not enough for mca to simulate them properly. In these
cases, there are two main possibilities:
1. The instruction has a dependency that isn’t detected by mca.
2. mca is incorrectly enforcing a dependency that shouldn’t exist.
For the rest of this discussion, I will be focusing on (1), but I have put some
thought into (2) and I may revisit it in the future.
So we have an instruction that has dependencies that aren’t picked up by mca.
The basic idea for both pipelines in mca is that when an instruction wants to be
dispatched, we first check for register hazards and then we check for resource
hazards. This is where CB is injected. If no register or resource hazards have
been detected, we make a call to CustomBehaviour::checkCustomHazard() to give
the target specific CB the chance to detect and enforce any custom dependencies.
The return value for checkCustomHazaard() is an unsigned int representing the
(minimum) number of cycles that the instruction needs to stall for. It’s fine to
underestimate this value because when StallCycles gets down to 0, we’ll end up
checking for all the hazards again before the instruction is actually
dispatched. However, it’s important not to overestimate the value and the more
accurate your estimate is, the more efficient mca’s execution can be.
In general, for checkCustomHazard() to be able to detect these custom
dependencies, it needs information about the current instruction and also all of
the instructions that are still executing within the pipeline. The mca pipeline
uses mca::Instruction rather than MCInst and the current information encoded
within each mca::Instruction isn’t sufficient for my use cases. I had to add a
few extra attributes to the mca::Instruction class and have them get set by the
MCInst during instruction building. For example, the current mca::Instruction
doesn’t know its opcode, and it also doesn’t know anything about its immediate
operands (both of which I had to add to the class).
With information about the current instruction, a list of all currently
executing instructions, and some target specific objects (MCSubtargetInfo and
MCInstrInfo which the base CB class has references to), developers should be
able to detect and enforce most custom dependencies within checkCustomHazard. If
you need more information than is present in the mca::Instruction, feel free to
add attributes to that class and have them set during the lowering sequence from
MCInst.
Fortunately, in the in-order pipeline, it’s very convenient for us to pass these
arguments to checkCustomHazard. The hazard checking is taken care of within
InOrderIssueStage::canExecute(). This function takes a const InstRef as a
parameter (representing the instruction that currently wants to be dispatched)
and the InOrderIssueStage class maintains a SmallVector<InstRef, 4> which holds
all of the currently executing instructions. For the out-of-order pipeline, it’s
a bit trickier to get the list of executing instructions and this is why I have
held off on implementing it myself. This is the main topic I will bring up when
I eventually make a post to discuss and ask for feedback.
CB is a base class where targets implement their own derived classes. If a
target specific CB does not exist (or we pass in the -disable-cb flag), the base
class is used. This base class trivially returns 0 from its checkCustomHazard()
implementation (meaning that the current instruction needs to stall for 0 cycles
aka no hazard is detected). For this reason, targets or users who choose not to
use CB shouldn’t see any negative impacts to accuracy or performance (in
comparison to pre-patch llvm-mca).
Differential Revision: https://reviews.llvm.org/D104149
Aaron Ballman [Tue, 15 Jun 2021 20:08:54 +0000 (16:08 -0400)]
Adding the rest of the C11 papers to the status page.
LLVM GN Syncbot [Tue, 15 Jun 2021 20:04:02 +0000 (20:04 +0000)]
[gn build] Port
6478ef61b1a4
Arthur Eubanks [Thu, 22 Apr 2021 20:03:09 +0000 (13:03 -0700)]
[InstSimplify] Treat invariant group insts as bitcasts for load operands
We can look through invariant group intrinsics for the purposes of
simplifying the result of a load.
Since intrinsics can't be constants, but we also don't want to
completely rewrite load constant folding, we convert the load operand to
a constant. For GEPs and bitcasts we just treat them as constants. For
invariant group intrinsics, we treat them as a bitcast.
Relanding with a check for self-referential values.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D101103
Vitaly Buka [Tue, 15 Jun 2021 00:52:14 +0000 (17:52 -0700)]
[asan] Remove Asan, Ubsan support of RTEMS and Myriad
Differential Revision: https://reviews.llvm.org/D104279
Vitaly Buka [Tue, 15 Jun 2021 19:31:38 +0000 (12:31 -0700)]
[NFC] Fix "unused variable" warning
Arpith C. Jacob [Tue, 15 Jun 2021 19:51:30 +0000 (12:51 -0700)]
Support lowering of index-cast on vector types.
The index cast operation accepts vector types. Implement its lowering in this patch.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D104280
Douglas Yung [Tue, 15 Jun 2021 19:46:03 +0000 (12:46 -0700)]
Remove redundant test that was causing intermittent build bot failures.
Patch by Fred Grim!
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D104295
Jinsong Ji [Tue, 15 Jun 2021 19:26:20 +0000 (19:26 +0000)]
[NFC] Update renamed option in comments
c98ebda325c996b3a12f4fded0368734dc0fe28a Rename fp-op fusion option (yet
again) for compatibility with GCC option.
The comment in the header should be updated too to avoid confusion.
Christopher Di Bella [Sat, 12 Jun 2021 06:13:44 +0000 (06:13 +0000)]
[libcxx][iwyu] ensures we IWYU as prep for modules
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.
Differential Revision: https://reviews.llvm.org/D104175
Quinn Pham [Tue, 15 Jun 2021 19:24:28 +0000 (14:24 -0500)]
[PowerPC] Moving defineXLCompatMacros() definition
Moving the definition of the defineXLCompatMacros function from
the header file clang/lib/Basic/Targets/PPC.h to the source file
clang/lib/Basic/Targets/PPC.cpp.
Differential revision: https://reviews.llvm.org/D104125
Nemanja Ivanovic [Tue, 15 Jun 2021 19:11:24 +0000 (14:11 -0500)]
[PowerPC] Fix spilling of paired VSX registers
We have added STXVP/LXVP for spilling and restoring the registers
but we neglected to add FI elimination code for these. The result
is that we end up producing impossible MachineInstr's that have
register operands in place of immediates.
Arthur O'Dwyer [Tue, 25 May 2021 18:34:18 +0000 (14:34 -0400)]
[libc++] [P0619] Add _LIBCPP_ABI_NO_BINDER_BASES and remove binder typedefs in C++20.
Differential Revision: https://reviews.llvm.org/D103753
Duncan P. N. Exon Smith [Tue, 15 Jun 2021 19:04:09 +0000 (12:04 -0700)]
Support: Remove F_{None,Text,Append} compatibility synonyms, NFC
Remove the compatibility spellings of `OF_{None,Text,Append}` that
were left behind by
1f67a3cba9b09636c56e2109d8a35ae96dc15782.
No functionality change here, just an API cleanup.
Differential Revision: https://reviews.llvm.org/D101506
Bob Haarman [Wed, 9 Jun 2021 20:41:26 +0000 (13:41 -0700)]
[X86] avoid assert with varargs, soft float, and no-implicit-float
Fixes:
- PR36507 Floating point varargs are not handled correctly with
-mno-implicit-float
- PR48528 __builtin_va_start assumes it can pass SSE registers
when using -Xclang -msoft-float -Xclang -no-implicit-float
On x86_64, floating-point parameters are normally passed in XMM
registers. For va_start, we spill those to memory so va_arg can
find them. There is an interaction here with -msoft-float and
-no-implicit-float:
When -msoft-float is in effect, instead of passing floating-point
parameters in XMM registers, they are passed in general-purpose
registers.
When -no-implicit-float is in effect, it "disables implicit
floating-point instructions" (per the LangRef). The intended
effect is to not have the compiler generate floating-point code
unless explicit floating-point operations are present in the
source code, but what exactly counts as an explicit floating-point
operation is not specified. The existing behavior of LLVM here has
led to some surprises and PRs.
This change modifies the behavior as follows:
| soft | no-implicit | old behavior | new behavior |
| no | no | spill XMM regs | spill XMM regs |
| yes | no | don't spill XMM | don't spill XMM |
| no | yes | don't spill XMM | spill XMM regs |
| yes | yes | assert | don't spill XMM |
In particular, this avoids the assert that happens when
-msoft-float and -no-implicit-float are both in effect. This
seems like a perfectly reasonable combination: If we don't want
to rely on hardware floating-point support, we want to both
avoid using float registers to pass parameters and avoid having
the compiler generate floating-point code that wasn't in the
original program. Instead of crashing the compiler, the new
behavior is to not synthesize floating-point code in this
case. This fixes PR48528.
The other interesting case is when -no-implicit-float is in
effect, but -msoft-float is not. In that case, any floating-point
parameters that are present will be in XMM registers, and so we
have to spill them to correctly handle those. This fixes
PR36507. The spill is conditional on %al indicating that
parameters are present in XMM registers, so no floating-point
code will be executed unless the function is called with
floating-point parameters.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D104001
Stanislav Mekhanoshin [Tue, 15 Jun 2021 18:02:34 +0000 (11:02 -0700)]
[AMDGPU] Fix lds superalign test. NFC.
Leonard Chan [Tue, 15 Jun 2021 17:45:06 +0000 (10:45 -0700)]
[compiler-rt][hwasan] Add GetShadowOffset function
Similar to SHADOW_OFFSET on asan, we can use this for hwasan so platforms that
use a constant value for the start of shadow memory can just use the constant
rather than access a global.
Differential Revision: https://reviews.llvm.org/D104275
Roman Lebedev [Tue, 15 Jun 2021 17:32:43 +0000 (20:32 +0300)]
[NewPM] Remove SpeculateAroundPHIs pass
Addition of this pass has been botched.
There is no particular reason why it had to be sold as an inseparable part
of new-pm transition. It was added when old-pm was still the default,
and very *very* few users were actually tracking new-pm,
so it's effects weren't measured.
Which means, some of the turnoil of the new-pm transition
are actually likely regressions due to this pass.
Likewise, there has been a number of post-commit feedback
(post new-pm switch), namely
* https://reviews.llvm.org/D37467#2787157 (regresses HW-loops)
* https://reviews.llvm.org/D37467#2787259 (should not be in middle-end, should run after LSR, not before)
* https://reviews.llvm.org/D95789 (an attempt to fix bad loop backedge metadata)
and in the half year past, the pass authors (google) still haven't found time to respond to any of that.
Hereby it is proposed to backout the pass from the pipeline,
until someone who cares about it can address the issues reported,
and properly start the process of adding a new pass into the pipeline,
with proper performance evaluation.
Furthermore, neither google nor facebook reports any perf changes
from this change, so i'm dropping the pass completely.
It can always be re-reverted should/if anyone want to pick it up again.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D104099
Raphael Isemann [Tue, 15 Jun 2021 17:23:51 +0000 (19:23 +0200)]
[lldb] Make the ClassTemplateDecl merging logic in TypeSystemClang respect template parameters
DWARF doesn't describe templates itself but only actual template instantiations.
Because of that LLDB has to infer the parameters of the class template
declarations from the actual instantiations when creating the internal Clang AST
from debug info
Because there is no dedicated DIE for the class template, LLDB also creates the
`ClassTemplateDecl` implicitly when parsing a template instantiation. To avoid
creating one ClassTemplateDecls for every instantiation,
`TypeSystemClang::CreateClassTemplateDecl` will check if there is already a
`ClassTemplateDecl` in the requested `DeclContext` and will reuse a found
fitting declaration.
The logic that checks if a found class template fits to an instantiation is
currently just comparing the name of the template. So right now we map
`template<typename T> struct S;` to an instantiation with the values `S<1, 2,
3>` even though they clearly don't belong together.
This causes crashes later on when for example the Itanium mangler's
`TemplateArgManglingInfo::needExactType` method tries to find fitting the class
template parameter that fits to an instantiation value. In the example above it
will try to find the parameter for the value `2` but will just trigger a
boundary check when retrieving the parameter with index 1 from the class
template.
There are two ways we can end up with an instantiation that doesn't fit to a
class template with the same name:
1. We have two TUs with two templates that have the same name and internal
linkage.
2. A forward declared template instantiation is emitted by GCC and Clang
without an empty list of parameter values.
This patch makes the check for whether a class template declaration can be
reused more sophisticated by also comparing whether the parameter values can fit
to the found class template. If we can't find a fitting class template we
justcreate a second class template with the fitting parameters.
Fixes rdar://
76592821
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D100662
David Green [Tue, 15 Jun 2021 17:19:25 +0000 (18:19 +0100)]
Revert "[ARM] Extend narrow values to allow using truncating scatters"
This commit adds nodes that might not always be used, which the
expensive checks builder does not like. Reverting for now to think up a
better way of handling it.
Arthur Eubanks [Fri, 4 Jun 2021 19:07:03 +0000 (12:07 -0700)]
[NFC][OpaquePtr] Avoid calling getPointerElementType()
Pointee types are going away soon.
For this, we mostly just care about store/load types, which are already
available without the pointee types. The other intrinsics always use
i8*.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D103719
Arthur Eubanks [Fri, 4 Jun 2021 17:56:57 +0000 (10:56 -0700)]
[NFC] Remove redundant variable
Differential Revision: https://reviews.llvm.org/D103706
Yuki Okushi [Tue, 15 Jun 2021 16:11:50 +0000 (09:11 -0700)]
Remove unnecessary triple from test
PR27098(https://bugs.llvm.org/show_bug.cgi?id=27098) has been fixed so
the avoidance seems unnecessary.
Differential Revision: https://reviews.llvm.org/D68891
David Green [Tue, 15 Jun 2021 16:45:14 +0000 (17:45 +0100)]
[ARM] Extend narrow values to allow using truncating scatters
As a minor adjustment to the existing lowering of offset scatters, this
extends any smaller-than-legal vectors into full vectors using a zext,
so that the truncating scatters can be used. Due to the way MVE
legalizes the vectors this should be cheap in most situations, and will
prevent the vector from being scalarized.
Differential Revision: https://reviews.llvm.org/D103704
Saleem Abdulrasool [Tue, 15 Jun 2021 02:41:30 +0000 (19:41 -0700)]
DirectoryWatcher: close a possible window of race on Windows
The initial scan occurring before the watcher is ready allows a race
condition where a change occurs before the initial scan completes.
Ensure that we wait for the watcher to begin executing the initial scan.
Addresses some feedback from Adrian McCarthy in post-commit review.
David Green [Tue, 15 Jun 2021 16:06:15 +0000 (17:06 +0100)]
[ARM] Use rq gather/scatters for smaller v4 vectors
A pointer will always fit into an i32, so a rq offset gather/scatter can
be used with v4i8 and v4i16 gathers, using a base of 0 and the Ptr as
the offsets. The rq gather can then correctly extend the type, allowing
us to use the gathers without falling back to scalarizing.
This patch rejigs tryCreateMaskedGatherOffset in the
MVEGatherScatterLowering pass to decompose the Ptr into Base:0 +
Offset:Ptr (with a scale of 1), if the Ptr could not be decomposed from
a GEP. v4i32 gathers will already use qi gathers, this extends that to
v4i8 and v4i16 gathers using the extending rq variants.
Differential Revision: https://reviews.llvm.org/D103674
Andrew Litteken [Mon, 7 Jun 2021 16:05:46 +0000 (11:05 -0500)]
[IROutliner] Adding DebugInfo handling for IR Outlined Functions
This adds support for functions outlined by the IR Outliner to be
recognized by the debugger. The expected behavior is that it will
skip over the instructions included in that section. This is due to the
fact that we can not say which of the original locations the
instructions originated from.
These functions will show up in the call stack, but you cannot step
through them.
Reviewers: paquette, vsk, djtodoro
Differential Revision: https://reviews.llvm.org/D87302
Tobias Gysi [Tue, 15 Jun 2021 13:32:12 +0000 (13:32 +0000)]
[mlir][linalg] Adapt yaml codegen to support scalar parameters.
The patch updates the C++ yaml code generation to support scalar operands as added in https://reviews.llvm.org/D104220.
Differential Revision: https://reviews.llvm.org/D104224
Adrian Prantl [Tue, 15 Jun 2021 15:17:28 +0000 (08:17 -0700)]
Work around MSVC compiler intricacies.
Isaac Perry [Thu, 13 May 2021 13:52:01 +0000 (14:52 +0100)]
[flang] [openmp] Add Fortran specific semantic check 4 for OpenMP Allocate directive.
This patch adds the 4th Fortran specific semantic check for the OpenMP
allocate directive: "If a list item has the SAVE attribute, is a common
block name, or is declared in the scope of a module, then only predefined
memory allocator parameters can be used in the allocator clause".
Code in this patch was based on code from https://reviews.llvm.org/D93549/new/.
Differential Revision: https://reviews.llvm.org/D102400