- Add alignment attribute to DIVariable family
- Modify bitcode format to match new DIVariable representation
- Update tests to match these changes (also add bitcode upgrade test)
- Expect that frontend passes non-zero align value only when it is not default
(was forcibly aligned by alignas()/_Alignas()/__atribute__(aligned())
Differential Revision: https://reviews.llvm.org/D25073
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284678 91177308-0d34-0410-b5e6-96231b3b80d8
r284611 changed the behavior of the DAG legalizer for sign-extending i1
values. Update the wasm extending load test to match.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284677 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have dropped MSVC 2013, all supported compilers support
noexcept and we can drop this portability macro.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284672 91177308-0d34-0410-b5e6-96231b3b80d8
load commands that use the MachO::thread_command type
but are not used in llvm libObject code but used in llvm tool code.
This includes the LC_UNIXTHREAD and LC_THREAD
load commands.
A quick note about the philosophy of the error checking in
libObject for Mach-O files, the idea behind the checking is
that we never will return a Mach-O file out of libObject that
contains unknown things in the load commands.
To do this the 32-bit ARM and PPC general tread states
needed to be defined as two test case binaries contained
them. If other thread states for other CPUs need to be
added we will do that as needed.
Going forward the LC_MAIN load command is used to
set the entry point in Mach-O executables these days
instead of an LC_UNIXTHREAD as was done in the past.
So today only in core files are LC_THREAD load commands
and thread states usually found.
Other thread states have not yet been defined in
include/Support/MachO.h at this time. But that can be
added as needed with their corresponding checking also
added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284668 91177308-0d34-0410-b5e6-96231b3b80d8
Profile runtime can generate an empty raw profile (when there is no function in
the shared library). This empty profile is treated as a text format profile. A
test format profile without the flag of "#IR" is thought to be a clang
generated profile. So in llvm profile merging, we will get a bogus warning of
"Merge IR generated profile with Clang generated profile."
The fix here is to skip the empty profile (when the buffer size is 0) for
profile merge.
Reviewers: vsk, davidxl
Differential Revision: http://reviews.llvm.org/D25687
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284659 91177308-0d34-0410-b5e6-96231b3b80d8
Chapter 5.
Chapter 5 demonstrates remote JITing: code is executed on the remote, not the
machine running the REPL, so it's the remote's triple (and TargetMachine) that
we need.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284657 91177308-0d34-0410-b5e6-96231b3b80d8
These tests rely on two sections being allocated with a limited displacement
from one to the other to work. We've never guaranteed this, and consequently
these tests usually fail. That led to them being XFAILed, but now they XPASS
whenever the sections do happen to be allocated nearby in memory. So I'm
removing these for now to get rid of the noise. We can re-instate them if/when
we take the time to implement a displacement-respecting allocator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284654 91177308-0d34-0410-b5e6-96231b3b80d8
This patch builds on clang r284648, and allows the runtime directory to make the bootstrap builds depend on the builtin libraries.
This patch also make the bootstrap build depend on configuring the other runtimes because the libcxx headers are copied during configuration. I have left a TODO in the code to remove that once I come up with a better solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284650 91177308-0d34-0410-b5e6-96231b3b80d8
0 - X --> X, if X is 0 or the minimum signed value
0 - X --> 0, if X is 0 or the minimum signed value and the sub is NSW
I noticed this pattern might be created in the backend after the change from D25485,
so we'll want to add a similar fold for the DAG.
The use of computeKnownBits in InstSimplify may be something to investigate if the
compile time of InstSimplify is noticeable. We could replace computeKnownBits with
specific pattern matchers or limit the recursion.
Differential Revision: https://reviews.llvm.org/D25785
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284649 91177308-0d34-0410-b5e6-96231b3b80d8
This code crashed on funclet-style EH instructions such as catchpad,
catchswitch, and cleanuppad. Just treat all EH pad instructions
equivalently and avoid merging the globals they reference through any
use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284633 91177308-0d34-0410-b5e6-96231b3b80d8
Some instructions from the original loop, when vectorized, can become trivially
dead. This happens because of the way we structure the new loop. For example,
we create new induction variables and induction variable "steps" in the new
loop. Thus, when we go to vectorize the original induction variable update, it
may no longer be needed due to the instructions we've already created. This
patch prevents us from creating these redundant instructions. This reduces code
size before simplification and allows greater flexibility in code generation
since we have fewer unnecessary instruction uses.
Differential Revision: https://reviews.llvm.org/D25631
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284631 91177308-0d34-0410-b5e6-96231b3b80d8
This change is motivated by the case when IndVarSimplify doesn't widen a comparison of IV increment because it can't prove IV increment being non-negative. We end up with a redundant trunc of the widened increment on this example.
for.body:
%i = phi i32 [ %start, %for.body.lr.ph ], [ %i.inc, %for.inc ]
%within_limits = icmp ult i32 %i, 64
br i1 %within_limits, label %continue, label %for.end
continue:
%i.i64 = zext i32 %i to i64
%arrayidx = getelementptr inbounds i32, i32* %base, i64 %i.i64
%val = load i32, i32* %arrayidx, align 4
br label %for.inc
for.inc:
%i.inc = add nsw nuw i32 %i, 1
%cmp = icmp slt i32 %i.inc, %limit
br i1 %cmp, label %for.body, label %for.end
There is a range check inside of the loop which guarantees the IV to be non-negative. NSW on the increment guarantees that the increment is also non-negative. Teach IndVarSimplify to use the range check to prove non-negativity of loop increments.
Reviewed By: sanjoy
Differential Revision: https://reviews.llvm.org/D25738
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284629 91177308-0d34-0410-b5e6-96231b3b80d8
This augments the STLExtras toolset with a zip iterator and range
adapter. Zip comes in two varieties: `zip`, which will zip to the
shortest of the input ranges, and `zip_first`, which limits its
`begin() == end()` checks to just the first range.
Recommit r284035 after MSVC2013 support has been dropped.
Patch by: Bryant Wong <github.com/bryant>
Differential Revision: https://reviews.llvm.org/D23252
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284623 91177308-0d34-0410-b5e6-96231b3b80d8
Initializing a ThreadPool with ThreadCount = 1 spawns a thread even
though we don't need to. This is at least slower than it needs to be,
and at worst may somehow be exacerbating PR30735 (llvm-cov times out
on ARM bots).
As a follow-up, I'll try to add logic to llvm::ThreadPool to avoid
spawning a thread when ThreadCount = 1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284621 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Changes default backend parallelism from thread::hardware_concurrency to
the new llvm::heavyweight_hardware_concurrency, which for X86 Linux
defaults to the number of physical cores (and will fall back to
thread::hardware_concurrency otherwise). This avoid oversubscribing
the physical cores using hyperthreading.
Reviewers: mehdi_amini, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25775
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284618 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r284590 as it fails on the mingw buildbot. I think I know the
fix, but I cannot test it right now. Will reapply when I verify it works ok.
This reverts r284590.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284615 91177308-0d34-0410-b5e6-96231b3b80d8
This required reengineering of some of the part of liveness calculation,
including fixing some issues caused by the limitations of the previous
approach. The current code is not necessarily the fastest, but it should
be functionally correct (at least more so than before). The compile-time
performance will be addressed in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284609 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
std::chrono mostly covers the functionality of llvm::sys::TimeValue and
lldb_private::TimeValue. This header adds a bit of utility functions and
typedefs, which make the usage of the library and porting code from TimeValues
easier.
Rationale:
- TimePoint typedef - precision of system_clock is implementation defined -
using a well-defined precision helps maintain consistency between platforms,
makes it interact better with existing TimeValue classes, and avoids cases
there a time point is implicitly convertible to a specific precision on some
platforms but not on others.
- system_clock::to_time_t only accepts time_points with the default system
precision (even though time_t has only second precision on all platforms we
support). To avoid the need for explicit casts, I have added a toTimeT()
wrapper function. toTimePoint(time_t) was not strictly necessary, but I have
added it for symmetry.
Reviewers: zturner, mehdi_amini
Subscribers: beanz, mgorny, llvm-commits, modocache
Differential Revision: https://reviews.llvm.org/D25416
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284590 91177308-0d34-0410-b5e6-96231b3b80d8
Most z13 vector instructions have a base form where the data type of
the operation (whether to consider the vector to be 16 bytes, 8
halfwords, 4 words, or 2 doublewords) is encoded into a mask field,
and then a set of extended mnemonics where the mask field is not
present but the data type is encoded into the mnemonic name.
Currently, LLVM only supports the type-specific forms (since those
are really the ones needed for code generation), but not the base
type-generic forms.
To complete the assembler support and make it fully compatible with
the GNU assembler, this commit adds assembler aliases for all the
base forms of the various vector instructions.
It also adds two more alias forms that are documented in the PoP:
VFPSO/VFPSODB/WFPSODB -- generic form of VFLCDB etc.
VNOT -- special variant of VNO
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284586 91177308-0d34-0410-b5e6-96231b3b80d8
The vfee[bhf], vfene[bhf], and vistr[bhf] assembler mnemonics are
documented in the Principles of Operation to have an optional last
operand to encode arbitrary values in a mask field.
This commit adds support for those optional operands, and cleans up
the patterns to generate vector string instruction as bit. No change
to code generation intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284585 91177308-0d34-0410-b5e6-96231b3b80d8
