George Rimar [Thu, 15 Aug 2019 13:39:58 +0000 (13:39 +0000)]
[lib/Object] - Remove objdump-file-header.test
objdump-file-header.test is placed in the wrong folder.
I removed it and updated the existent llvm-objdump test cases with
the updated content of the file removed.
Set the StartIdx type to size_t so that it matches the StoreNodes SmallVector size() and index types.
Silences the MSVC analyzer warning that unsigned increment might overflow before exceeding size_t on 64-bit targets - this isn't likely to happen but it means we use consistent types and reduces the warning "noise" a little.
Kang Zhang [Thu, 15 Aug 2019 13:05:16 +0000 (13:05 +0000)]
[CodeGen] Do the Simple Early Return in block-placement pass to optimize the blocks
Summary:
This patch has trigger a bug of r368339, and the r368339 has been reverted, So upstream this patch again.
In `block-placement` pass, it will create some patterns for unconditional we can do the simple early retrun.
But the `early-ret` pass is before `block-placement`, we don't want to run it again.
This patch is to do the simple early return to optimize the blocks at the last of `block-placement`.
David Green [Thu, 15 Aug 2019 12:54:47 +0000 (12:54 +0000)]
[ARM] Fix alignment checks for BE VLDRH
We need to allow any alignment at least 2, not just exactly 2, so that the big
endian loads and stores can be selected successfully. I've also added extra BE
testing for the load and store tests.
Sanjay Patel [Thu, 15 Aug 2019 12:43:15 +0000 (12:43 +0000)]
[SDAG][x86] check for relaxed math when matching an FP reduction
If the last step in an FP add reduction allows reassociation and doesn't care
about -0.0, then we are free to recognize that computation as a reduction
that may reorder the intermediate steps.
This is requested directly by PR42705:
https://bugs.llvm.org/show_bug.cgi?id=42705
and solves PR42947 (if horizontal math instructions are actually faster than
the alternative):
https://bugs.llvm.org/show_bug.cgi?id=42947
Andrea Di Biagio [Thu, 15 Aug 2019 12:39:55 +0000 (12:39 +0000)]
[MCA] Slightly refactor the logic in ResourceManager. NFCI
This patch slightly changes the API in the attempt to simplify resource buffer
queries. It is done in preparation for a patch that will enable support for
macro fusion.
Florian Hahn [Thu, 15 Aug 2019 12:13:02 +0000 (12:13 +0000)]
[ValueTracking] Add MustPreserveNullness arg to functions analyzing calls. (NFC)
Some uses of getArgumentAliasingToReturnedPointer and
isIntrinsicReturningPointerAliasingArgumentWithoutCapturing require the
calls/intrinsics to preserve the nullness of the argument.
For alias analysis, the nullness property does not really come into
play.
This patch explicitly sets it to true. In D61669, the alias analysis
uses will be switched to not require preserving nullness.
Sander de Smalen [Thu, 15 Aug 2019 10:34:16 +0000 (10:34 +0000)]
[AArch64] Change location of frame-record within callee-save area.
This patch changes the location of the frame-record (FP, LR) to the
bottom of the callee-saved area. According to the AAPCS the location of
the frame-record within the stackframe is unspecified (section 5.2.3 The
Frame Pointer), so the compiler should be free to choose a different
location.
The reason for changing the location of the frame-record is to prepare
the frame for allocating an SVE area below the callee-saves. This way the
compiler can use the VL-scaled addressing modes to directly access SVE
objects from the frame-pointer.
Things to point out:
- The algorithm to find a paired register should be prevented from
accidentally pairing some callee-saved register with LR that is not
FP, since they should always be paired together when the frame
has a frame-record.
- For Darwin platforms the location of the frame-record is unchanged,
since the unwind encoding does not allow for encoding this position
dynamically and other tools currently depend on the former layout.
Florian Hahn [Thu, 15 Aug 2019 10:12:26 +0000 (10:12 +0000)]
Add ptrmask intrinsic
This patch adds a ptrmask intrinsic which allows masking out bits of a
pointer that must be zero when accessing it, because of ABI alignment
requirements or a restriction of the meaningful bits of a pointer
through the data layout.
This avoids doing a ptrtoint/inttoptr round trip in some cases (e.g. tagged
pointers) and allows us to not lose information about the underlying
object.
Pavel Labath [Thu, 15 Aug 2019 08:20:15 +0000 (08:20 +0000)]
MemoryBuffer: Add a missing error-check to getOpenFileImpl
Summary:
In case the function was called with a desired read size *and* the file
was not an "mmap()" candidate, the function was falling back to a
"pread()", but it was failing to check the result of that system call.
This meant that the function would return "success" even though the read
operation failed, and it returned a buffer full of uninitialized memory.
Dorit Nuzman [Thu, 15 Aug 2019 07:12:14 +0000 (07:12 +0000)]
[LV] fold-tail predication should be respected even with assume_safety
assume_safety implies that loads under "if's" can be safely executed
speculatively (unguarded, unmasked). However this assumption holds only for the
original user "if's", not those introduced by the compiler, such as the
fold-tail "if" that guards us from loading beyond the original loop trip-count.
Currently the combination of fold-tail and assume-safety pragmas results in
ignoring the fold-tail predicate that guards the loads, generating unmasked
loads. This patch fixes this behavior.
Craig Topper [Thu, 15 Aug 2019 05:52:02 +0000 (05:52 +0000)]
[X86] Remove unneeded isel pattern for v4f32->v4i32 fp_to_sint and conversion to MMX.
fp_to_sint is turned into X86cvttp2si during isel preprocessing.
The other redundant isel patterns were removed previously, but I
missed this one because its in the MMX td file.
Craig Topper [Thu, 15 Aug 2019 04:07:43 +0000 (04:07 +0000)]
[X86] Remove some dead code and combine some repeated code that's left.
If the width is 256 bits, then we must have AVX so the else here
was unnecessary. Once that's removed then the >= 256 bit code is
identical to the 128 bit code with a different VT so combine them.
Gor Nishanov [Thu, 15 Aug 2019 00:48:51 +0000 (00:48 +0000)]
[coroutine] Fixes "cannot move instruction since its users are not dominated by CoroBegin" problem.
Summary:
Fixes https://bugs.llvm.org/show_bug.cgi?id=36578 and https://bugs.llvm.org/show_bug.cgi?id=36296.
Supersedes: https://reviews.llvm.org/D55966
One of the fundamental transformation that CoroSplit pass performs before splitting the coroutine is to find which values need to survive between suspend and resume and provide a slot for them in the coroutine frame to spill and restore the value as needed.
Coroutine frame becomes available once the storage for it was allocated and that point is marked in the pre-split coroutine with a llvm.coro.begin intrinsic.
FE normally puts all of the user-authored code that would be accessing those values after llvm.coro.begin, however, sometimes instructions accessing those values would end up prior to coro.begin. For example, writing out a value of the parameter into the alloca done by the FE or instructions that are added by the optimization passes such as SROA when it rewrites allocas.
Prior to this change, CoroSplit pass would try to move instructions that may end up accessing the values in the coroutine frame after CoroBegin. However it would run into problems (report_fatal_error) if some of the values would be used both in the allocation function (for example allocator is passed as a parameter to a coroutine) and in the use-authored body of the coroutine.
To handle this case and to simplify the instruction moving logic, this change removes all of the instruction moving. Instead, we only change the uses of the spilled values that are dominated by coro.begin and leave other instructions intact.
Before:
```
%var = alloca i32
%1 = getelementptr .. %var; ; will move this one after coro.begin
%f = call i8* @llvm.coro.begin(
```
After:
```
%var = alloca i32
%1 = getelementptr .. %var; stays put
%f = call i8* @llvm.coro.begin(
```
If we discover that there is a potential write into an alloca, prior to coro.begin we would copy its value from the alloca into the spill slot in the coroutine frame.
Before:
```
%var = alloca i32
store .. %var ; will move this one after coro.begin
%f = call i8* @llvm.coro.begin(
```
After:
```
%var = alloca i32
store .. %var ;stays put
%f = call i8* @llvm.coro.begin(
%tmp = load %var
store %tmp, %spill.slot.for.var
```
Note: This change does not handle array allocas as that is something that C++ FE does not produce, but, it can be added in the future if need arises
Robert Widmann [Wed, 14 Aug 2019 23:54:35 +0000 (23:54 +0000)]
Expose TailCallKind via the LLVM C API
Summary: This exposes `CallInst`'s tail call kind via new `LLVMGetTailCallKind` and `LLVMSetTailCallKind` functions. The motivation for this is to be able to see `musttail` for languages that require mandatory tail calls for correctness. Today only the weaker `LLVMSetTail` is exposed and there is no way to set `GuaranteedTailCallOpt` via the C API.
Jordan Rupprecht [Wed, 14 Aug 2019 22:18:01 +0000 (22:18 +0000)]
[docs] Fix sphinx doc generation errors
Summary:
Errors fixed:
- GettingStarted: Duplicate explicit target name: "cmake"
- GlobalISel: Unexpected indentation
- LoopTerminology: Explicit markup ends without a blank line; unexpected unindent
- ORCv2: Definition list ends without a blank line; unexpected unindent
- Misc: document isn't included in any toctree
Verified that a clean docs build (`rm -rf docs/ && ninja docs-llvm-html`) passes with no errors. Spot checked the individual pages to make sure they look OK.
[Attributor] Use the AANoNull attribute directly in AADereferenceable
Summary:
Instead of constantly keeping track of the nonnull status with the
dereferenceable information we can simply query the nonnull attribute
whenever we need the information (debug + manifest).
[Attributor] Use liveness during the creation of AAReturnedValues
Summary:
As one of the first attributes, and one of the complex ones,
AAReturnedValues was not using liveness but we filtered the result after
the fact. This change adds liveness usage during the creation. The
algorithm is also improved and shorter.
The new algorithm will collect returned values over time using the
generic facilities that work with liveness already, e.g.,
genericValueTraversal which does not look at dead PHI node predecessors.
A test to show how this leads to better results is included.
Note: Unresolved calls and resolved calls are now tracked explicitly.
Summary:
The next attempt to clean up the Attributor interface before we grow it
further.
Before, we used a combination of two values (associated + anchor) and an
argument number (or -1) to determine a location. This was very fragile.
The new system uses exclusively IR positions and we restrict the
generation of IR positions to special constructor methods that verify
internal constraints we have. This will catch misuse early.
The auto-conversion, e.g., in getAAFor, is now performed through the
SubsumingPositionIterator. This iterator takes an IR position and allows
to visit all IR positions that "subsume" the given one, e.g., function
attributes "subsume" argument attributes of that function. For a
detailed breakdown see the class comment of SubsumingPositionIterator.
This patch also introduces the IRPosition::getAttrs() to extract IR
attributes at a certain position. The method knows how to look up in
different positions that are equivalent, e.g., the argument position for
call site arguments. We also introduce three new positions kinds such
that we have all IR positions where attributes can be placed and one for
"floating" values.
[Bugpoint redesign] Added Pass to Remove Global Variables
Summary:
This pass tries to remove Global Variables, as well as their derived uses. For example if a variable `@x` is used by `%call1` and `%call2`, both these uses and the definition of `@x` are deleted. Moreover if `%call1` or `%call2` are used elsewhere those uses are also deleted, and so on recursively.
I'm still uncertain if this pass should remove derived uses, I'm open to suggestions.
Erich Keane [Wed, 14 Aug 2019 19:55:59 +0000 (19:55 +0000)]
Add support in CMake to statically link the C++ standard library.
It is sometimes useful to have the C++ standard library linked into the
assembly when compiling clang, particularly when distributing a compiler
onto systems that don't have a copy of stdlibc++ or libc++ installed.
This functionality should work with either GCC or Clang as the host
compiler, though statically linking libc++ (as may be required for
licensing purposes) is only possible if the host compiler is Clang with
a copy of libc++ available.
We already supported rewriting loop exit values for multiple exit loops, but if any of the loop exits were not computable, we gave up on all loop exit values. This patch generalizes the existing code to handle individual computable loop exits where possible.
As discussed in the review, this is a starting point for figuring out a better API. The code is a bit ugly, but getting it in lets us test as we go.
Matt Arsenault [Wed, 14 Aug 2019 18:13:00 +0000 (18:13 +0000)]
InferAddressSpaces: Move target intrinsic handling to TTI
I'm planning on handling intrinsics that will benefit from checking
the address space enums. Don't bother moving the address collection
for now, since those won't need th enums.
Taewook Oh [Wed, 14 Aug 2019 17:58:45 +0000 (17:58 +0000)]
[DebugInfo] Consider debug label scope has an extra lexical block file
Summary: There are places where a case that debug label scope has an extra lexical block file is not considered properly. The modified test won't pass without this patch.
JF Bastien [Wed, 14 Aug 2019 17:39:07 +0000 (17:39 +0000)]
Move to C++14
Summary:
I just bumped the minimum compiler versions to support C++14 in D66188.
Following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) and [our previous agreement](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html), I'm now officially bumping the C++ version to 14 and updating the documentation.
After switching over LLDB's line table parser to libDebugInfo, we
noticed two regressions on the Windows bot. The problem is that when
obtaining a file from the line table prologue, we append paths without
specifying a path style. This leads to incorrect results on Windows for
debug info containing Posix paths:
Thomas Lively [Wed, 14 Aug 2019 16:24:37 +0000 (16:24 +0000)]
[WebAssembly] Stop unrolling SIMD shifts since they are fixed in V8
Summary:
Fixes PR42973. Tests don't change because simd-arith.ll tests behavior
on unimplemented-simd128, which does not include any temporary
workarounds such as the one removed in this revision.
Craig Topper [Wed, 14 Aug 2019 14:52:39 +0000 (14:52 +0000)]
[X86][CostModel] Adjust the costs of ZERO_EXTEND/SIGN_EXTEND with less than 128-bit inputs
Now that we legalize by widening, the element types here won't change. Previously these were modeled as the elements being widened and then the instruction might become an AND or SHL/ASHR pair. But now they'll become something like a ZERO_EXTEND_VECTOR_INREG/SIGN_EXTEND_VECTOR_INREG.
For AVX2, when the destination type is legal its clear the cost should be 1 since we have extend instructions that can produce 256 bit vectors from less than 128 bit vectors. I'm a little less sure about AVX1 costs, but I think the ones I changed were definitely too high, but they might still be too high.
Pavel Labath [Wed, 14 Aug 2019 13:59:04 +0000 (13:59 +0000)]
Revert "raw_ostream: add operator<< overload for std::error_code"
This reverts commit r368849, because it breaks some bots (e.g.
llvm-clang-x86_64-win-fast).
It turns out this is not as NFC as we had hoped, because operator== will
consider two std::error_codes to be distinct even though they both hold
"success" values if they have different categories.
Pavel Labath [Wed, 14 Aug 2019 13:33:28 +0000 (13:33 +0000)]
raw_ostream: add operator<< overload for std::error_code
Summary:
The main motivation for this is unit tests, which contain a large macro
for pretty-printing std::error_code, and this macro is duplicated in
every file that needs to do this. However, the functionality may be
useful elsewhere too.
In this patch I have reimplemented the existing ASSERT_NO_ERROR macros
to reuse the new functionality, but I have kept the macro (as a
one-liner) as it is slightly more readable than ASSERT_EQ(...,
std::error_code()).