| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 255981
|
|
|
|
|
|
|
| |
This reverts commit r255977. This is part of
http://reviews.llvm.org/D15634.
llvm-svn: 255978
|
|
|
|
| |
llvm-svn: 255977
|
|
|
|
| |
llvm-svn: 255973
|
|
|
|
|
|
|
|
|
|
|
| |
resolver. Also
have the breakpoint description print the precondition description if one exists.
No behavior change.
<rdar://problem/22885189>
llvm-svn: 255972
|
|
|
|
|
|
|
|
|
| |
Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h
so nothing should change for projects directly including the headers,
but transitive dependencies may be affected.
llvm-svn: 255965
|
|
|
|
| |
llvm-svn: 255944
|
|
|
|
|
|
|
|
|
|
| |
synthesizing.
When determining whether ownership was explicitly written for a
property when it is being synthesized, also consider that the original
property might have come from a protocol. Fixes rdar://problem/23931441.
llvm-svn: 255943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"thread-pcs" key is added to the T (questionmark) packet in
gdb-remote protocol so that lldb doesn't need to query the
pc values of every thread before it resumes a process.
The only odd part with this is that I'm sending the pc
values in big endian order, so we need to know the endianness
of the remote process before we can use them. All other
register values in gdb-remote protocol are sent in native-endian
format so this requirement doesn't exist. This addition is a
performance enhancement -- lldb will fall back to querying the
pc of each thread individually if it needs to -- so when
we don't have the byte order for the process yet, we don't
use these values. Practically speaking, the only way I've
been able to elicit this condition is for the first
T packet when we attach to a process.
<rdar://problem/21963031>
llvm-svn: 255942
|
|
|
|
|
|
|
| |
K-Ballo.
Review: http://reviews.llvm.org/D14839
llvm-svn: 255941
|
|
|
|
| |
llvm-svn: 255940
|
|
|
|
| |
llvm-svn: 255939
|
|
|
|
| |
llvm-svn: 255938
|
|
|
|
| |
llvm-svn: 255937
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the 3-byte (4 with REX prefix) push-pop sequence for materializing
small constants. This is smaller than using a mov (5, 6 or 7 bytes
depending on size and REX prefix), but it's likely to be slower, so
only used for 'minsize'.
This is a follow-up to r255656.
Differential Revision: http://reviews.llvm.org/D15549
llvm-svn: 255936
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--rerun-all-issues"
and
Revert "prevent rerun logic from kicking in on test runs including aarch64."
This reverts commits:
r255719
r255747
llvm-svn: 255935
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
probabilities cannot coexist when being normalized.
The current BranchProbability::normalizeProbabilities() forbids known and
unknown probabilities to coexist in the list. This was once used to help
capture probability exceptions but has caused some reported build
failures (https://llvm.org/bugs/show_bug.cgi?id=25838).
This patch removes this restriction by evenly distributing the complement
of the sum of all known probabilities to unknown ones. We could still
treat this as an abnormal behavior, but it is better to emit warnings in
our future profile validator.
Differential revision: http://reviews.llvm.org/D15548
llvm-svn: 255934
|
|
|
|
|
|
|
|
| |
* Pull in host-only implementations of few CUDA-specific math functions.
* #nclude <cmath> early to prevent its inclusion from CUDA headers after
they've messed with __THROW macro.
llvm-svn: 255933
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the same line of reasoning used in EarlyCSE w/http://reviews.llvm.org/D15352 to the DSE implementation in InstCombine.
Key points:
* We only remove unordered or simple stores.
* The loads producing values consumed by dead stores don't influence whether the store is dead.
Differential Revision: http://reviews.llvm.org/D15354
llvm-svn: 255932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I didn't realize that we already allowed atomic load/store of pointers,
it was added in 2012 by r162146. This patch updates the documentation
and tightens the verifier by using DataLayout to make sure that the
stored size is byte-sized and power-of-two. DataLayout is also used for
integers, and while I'm here I updated the corresponding code for
cmpxchg and rmw.
See the following discussion for context and upcoming changes to
add floating-point and vector atomics:
https://groups.google.com/forum/#!topic/llvm-dev/Nh0P_E3CRoo/discussion
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15512
llvm-svn: 255931
|
|
|
|
|
|
| |
Fixes pr25868.
llvm-svn: 255930
|
|
|
|
|
|
|
| |
Aaron Ballman pointed out a typo from the copy and paste in r255875. This will
preserve the strict weak ordering when comparing DynTypedNode.
llvm-svn: 255929
|
|
|
|
|
|
|
| |
This reverts commit r255895. The patch breaks internal tests. Reverting until a
fix is ready.
llvm-svn: 255928
|
|
|
|
|
|
| |
These functions were deprecated in r97608.
llvm-svn: 255927
|
|
|
|
| |
llvm-svn: 255926
|
|
|
|
| |
llvm-svn: 255925
|
|
|
|
| |
llvm-svn: 255924
|
|
|
|
| |
llvm-svn: 255923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch fixes Bug 25759 produced by inappropriate handling of unsigned
maximum SCEV expressions by SCEVRemoveMax. Without a fix, we get an infinite
loop and a segmentation fault, if we try to process, for example,
'((-1 + (-1 * %b1)) umax {(-1 + (-1 * %yStart)),+,-1}<%.preheader>)'.
It also fixes a potential issue related to signed maximum SCEV expressions.
Tested-by: Roman Gareev <gareevroman@gmail.com>
Fixed-by: Tobias Grosser <tobias@grosser.es>
Differential Revision: http://reviews.llvm.org/D15563
llvm-svn: 255922
|
|
|
|
| |
llvm-svn: 255921
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[InstCombine] Adding '\n' to debug output. NFC.
Patch by Zhaoshi Zheng <zhaoshiz@codeaurora.org>
Reviewers: apazos, majnemer, weimingz
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15403
llvm-svn: 255920
|
|
|
|
|
|
| |
This fixes a failure on Windows buildbots.
llvm-svn: 255919
|
|
|
|
|
|
|
|
| |
This sets the maximum entry count among all functions in the program to the module using module flags. This allows the optimizer to use this information.
Differential Revision: http://reviews.llvm.org/D15163
llvm-svn: 255918
|
|
|
|
|
|
|
| |
Some of the newer structures were not protected. Now that we have
a recursive lock, we just lock the whole handle_event() call.
llvm-svn: 255917
|
|
|
|
| |
llvm-svn: 255916
|
|
|
|
| |
llvm-svn: 255915
|
|
|
|
|
|
|
|
|
|
| |
The rules for removing trivially dead stores are a lot less complicated than loads. Since we know the later store post dominates the former and the former dominates the later, unless the former has side effects other than the actual store, we can remove it. One slightly surprising thing is that we can freely remove atomic stores, even if the later one isn't atomic. There's no guarantee the atomic one was every visible.
For the moment, we don't handle DSE of ordered atomic stores. We could extend the same chain of reasoning to them, but the catch is we'd then have to model the ordering effect without a store instruction. Since our fences are a stronger than our operation orderings, simple using a fence isn't an obvious win. This arguable calls for a refinement in our fence specification, but that's (much) later work.
Differential Revision: http://reviews.llvm.org/D15352
llvm-svn: 255914
|
|
|
|
| |
llvm-svn: 255913
|
|
|
|
| |
llvm-svn: 255912
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++ emits vtables for classes that have key function present in the
current TU. While we compile CUDA the fact that key function was found
in this TU does not mean that we are going to generate code for it. E.g.
vtable for a class with host-only methods should not (and can not) be
generated on device side, because we'll never generate code for them
during device-side compilation.
This patch adds an extra CUDA-specific check during key method computation
and filters out potential key methods that are not suitable for this side
of CUDA compilation.
When we codegen vtable, entries for unsuitable methods are set to null.
Differential Revision: http://reviews.llvm.org/D15309
llvm-svn: 255911
|
|
|
|
| |
llvm-svn: 255910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Second patch split out from http://reviews.llvm.org/D14752.
Maps metadata as a post-pass from each module when importing complete,
suturing up final metadata to the temporary metadata left on the
imported instructions.
This entails saving the mapping from bitcode value id to temporary
metadata in the importing pass, and from bitcode value id to final
metadata during the metadata linking postpass.
Depends on D14825.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D14838
llvm-svn: 255909
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15583
Patch by: Changpeng Fang
llvm-svn: 255908
|
|
|
|
|
|
| |
function
llvm-svn: 255907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The method insertNOPs expected the number of wait states to be passed as
parameter, while eliminateFrameIndex passed the immediate argument for the
S_NOP, leading to an off-by-one error. Rename the method to make the
meaning of its parameter clearer. The number of 4 / 5 wait states (which
is what the method has always _tried_ to do according to the comment) is
correct according to the hardware docs.
I stumbled upon this while trying to track down the cause of
https://bugs.freedesktop.org/show_bug.cgi?id=93264. While clearly needed,
this patch unfortunately does not fix that bug...
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15542
llvm-svn: 255906
|
|
|
|
|
|
|
|
| |
Clang has better diagnostics in this case. It is not necessary therefore
to change the destructor to avoid what is effectively an invalid warning
in gcc. Instead, better handle the warning flags given to the compiler.
llvm-svn: 255905
|
|
|
|
|
|
|
|
| |
Currently we can just inspect the details of the most common allocation types.
This patch allows us to support all the types defined by the RS runtime in its `RsDataType` enum.
Including handlers, matrices and packed graphical data.
llvm-svn: 255904
|
|
|
|
| |
llvm-svn: 255903
|
|
|
|
|
|
|
|
|
|
| |
These days relocations are created and stored in a deterministic way.
The order they are created is also suitable for the .o file, so we don't
need an explicit sort.
The last remaining exception is MIPS.
llvm-svn: 255902
|
|
|
|
| |
llvm-svn: 255901
|