Summary:
Fixing a bug I found when testing a reader for the FDR format. Function ID is
now correctly packed into the 28 bits which are documented for it instead of being
masked to all ones.
Reviewers: dberris, pelikan, eugenis
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29698
llvm-svn: 294563
We only implemented it for one of the 3 HLE instructions and that instruction is also under the RTM flag. Clang only implements the RTM flag from its command line.
llvm-svn: 294562
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
This patch does the following.
1. Adds an Intrinsic int_x86_clzero which works with __builtin_ia32_clzero
2. Identifies clzero feature using cpuid info. (Function:8000_0008, Checks if EBX[0]=1)
3. Adds the clzero feature under znver1 architecture.
4. The custom inserter is added in Lowering.
5. A testcase is added to check the intrinsic.
6. The clzero instruction is added to assembler test.
Patch by Ganesh Gopalasubramanian with a couple formatting tweaks, a disassembler test, and using update_llc_test.py from me.
Differential revision: https://reviews.llvm.org/D29385
llvm-svn: 294558
cctools would pad the string table to a sizeof(int32_t) (explicitly
printed out by cctools rather than 4). This adjusts the string table to
make it more compatible with cctools, but is insufficient to make ld64
happy.
llvm-svn: 294557
libunwind depends on C++ library headers. When building libunwind
as part of LLVM and libc++ is available, use its headers.
Differential Revision: https://reviews.llvm.org/D29573
llvm-svn: 294554
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29575
llvm-svn: 294553
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29574
llvm-svn: 294552
Functions that have a dynamic alloca require a base register which is defined to
be X19 on AArch64 and r6 on ARM. We have defined the swifterror register to be
the same register. Use a different callee save register for swifterror instead:
X21 on AArch64
R8 on ARM
rdar://30433803
llvm-svn: 294551
It turns out that some of our negative tests were not in fact providing the
test coverage we expected: they were passing because the vtables were failing
an early check that they were constant. Fix this by changing the globals in
these tests to constants.
llvm-svn: 294550
CommandObjectVersion.cpp calls lldb_private::GetVersion (present in lldbBase).
This should fix the unittest link on windows. I am not sure why is this not
present on other platforms -- my guess is that there lldbBase is included in
the link through some other dependency chain.
llvm-svn: 294549
It'll usually be immediately legalized back to a libcall, but occasionally
something can be done with it so we'd just as well enable that flexibility from
the start.
llvm-svn: 294530
We mark X0 as preserved by a call that passes the returned parameter.
x0 = ...
fun(x0) // no implicit def of x0
This no longer is valid if we pass the parameter in a different register then
the returned value as is the case with a swiftself parameter (passed in x20).
x20 = ...
fun(x20) // there should be an implict def of x8
rdar://30425845
llvm-svn: 294527
AArch64 has specific instructions to multiply two numbers at double the width
and produce the high part of the result. These can be used to implement LLVM's
mul.with.overflow instructions fairly simply. Helps with C++ operator new[].
llvm-svn: 294519
Implement getRegPressureLimit and getRegPressureSetLimit callbacks in
SIRegisterInfo.
This makes standard converge scheduler to behave almost the same as
GCNScheduler, sometime slightly better sometimes a bit worse.
In gerenal that is also possible to switch GCNScheduler to use these
callbacks instead of getMaxWaves(), which also makes GCNScheduler
slightly better on some tests and slightly worse on another. A big
win is behavior with converge scheduler.
Note, these are used not only by scheduling, but in places like
MachineLICM.
Differential Revision: https://reviews.llvm.org/D29700
llvm-svn: 294518
Summary:
This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool.
This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too.
Help testing would be greatly appreciated.
Reviewers: labath, zturner
Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits
Differential Revision: https://reviews.llvm.org/D29352
llvm-svn: 294515
Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies.
Reviewers: mgorny, chapuni, bryant
Subscribers: llvm-commits, jgosnell
Differential Revision: https://reviews.llvm.org/D28869
llvm-svn: 294514
In r293373 we switched the build to linking dynamically against the
Universal CRT and include the redistributables in the installer.
However, clang-format.exe is copied into the vsix and needs to be
statically linked. This commit makes us build the plugin in a separate
step that uses static linking.
llvm-svn: 294513
This module will contain nothing but vtable definitions and (soon)
available_externally function definitions, so there is no point in keeping
debug info in the module.
Differential Revision: https://reviews.llvm.org/D28913
llvm-svn: 294511
When building for Windows, we would check if we were using MSVC rather
than WIN32. This resulted in needed targets not being defined by
sanitizer_common. Fix the conditional.
When registering the objects libraries for ASAN, we would multiply
register for all targets as we were creating them inside a loop over all
architectures. Only define the target per architecture.
llvm-svn: 294510
Fix the test zlib conditional to use LLVM_ENABLE_ZLIB value when
building stand-alone. The HAVE_LIBZ is not available when performing
a stand-alone build. Since the zlib support is a feature of
the underlying LLVM library, it exports the actual status as the final
value of LLVM_ENABLE_ZLIB in LLVMConfig.
While at it, canonicalize the boolean value into 0/1 and remove unused
CMake definitions (most likely copied from clang).
Differential Revision: https://reviews.llvm.org/D29340
llvm-svn: 294508
Use both LLD- and LLVM-specific binary&library directories when LLD is
being built stand-alone. This ensures that the freshly built tools and
libraries are found and used correctly.
Without this patch, the test suite uses LLVM_TOOLS_DIR and LLVM_LIBS_DIR
to locate lld, and set PATH and LD_LIBRARY_PATH. When doing
a stand-alone builds, these variables represent the installed LLVM.
As a result, tests either fail due to missing lld executables/libraries
or use an earlier installed LLD version rather than the one being built.
To solve this, an additional LLD_TOOLS_DIR and LLD_LIBS_DIR variables
are added that are populated using LLVM_*_OUTPUT_INTDIR. Those variables
are populated with directories used to output built executables
and libraries. In stand-alone builds, they represent the directories
used by LLD. In integrated builds, they have the same values as
LLVM_*_DIR and therefore using them does not harm.
The new variables are prepended to PATH and LD_LIBRARY_PATH to ensure
that freshly built binaries are preferred over potentially earlier
installed ones. Furthermore, the resulting PATH is used to locate tools
for substitutions since the search includes both tools built as part of
LLD and of LLVM.
Differential Revision: https://reviews.llvm.org/D29335
llvm-svn: 294507
nested-name-specifier (as the standard appears to require), treat it as the
type specifier 'decltype(auto)' followed by a nested-name-specifier starting
with '::'.
llvm-svn: 294506
Making the cost model selecting between Interleave, GatherScatter or Scalar vectorization form of memory instruction.
The right decision should be done for non-consecutive memory access instrcuctions that may have more than one vectorization solution.
This patch includes the following changes:
- Cost Model calculates the cost of Load/Store vector form and choose the better option between Widening, Interleave, GatherScactter and Scalarization. Cost Model keeps the widening decision.
- Arrays of Uniform and Scalar values are moved from Legality to Cost Model.
- Cost Model collects Uniforms and Scalars per VF. The collection is based on CM decision map of Loadis/Stores vectorization form.
- Vectorization of memory instruction is performed according to the CM decision.
Differential Revision: https://reviews.llvm.org/D27919
llvm-svn: 294503
The test is failing on the bot because "/subsystem:console" was
truncated for some reason. I don't know why that is happening on
that machine (it is not reproducible on my Windows machine).
In this patch, I'm trying to tame it by making the output shorter.
llvm-svn: 294502
Dean Michael Berris