The system can create threads for a system threadpool, so there is
no guarantee that the thread that is stopped is thread 1. So use
a more robust check.
llvm-svn: 257513
Refactor .param, .result, .local, and .endfunc, as directives, using the
proper MCTargetStreamer mechanism, rather than fake instructions.
llvm-svn: 257511
This patch changes the way labels are referenced. Instead of referencing the
basic-block label name (eg. .LBB0_0), instructions now just have an immediate
which indicates the depth in the control-flow stack to find a label to jump to.
This makes them much closer to what we expect to have in the binary encoding,
and avoids the problem of basic-block label names not being explicit in the
binary encoding.
Also, it terminates blocks and loops with end_block and end_loop instructions,
rather than basic-block label names, for similar reasons.
This will also fix problems where two constructs appear to have the same label,
because we no longer explicitly use labels, so consumers that need labels will
presumably create their own labels, and presumably they won't reuse labels
when they do.
This patch does make the code a little more awkward to read; as a partial
mitigation, this patch also introduces comments showing where the labels are,
and comments on each branch showing where it's branching to.
llvm-svn: 257505
Summary:
Allows the remote to enumerate the link map when adding and removing
shared libraries, so that lldb doesn't need to read it manually from
the remote's memory.
This provides very large speedups (on the order of 50%) in total
startup time when using the ds2 remote on android or Tizen devices.
Reviewers: ADodds, tberghammer, tfiala
Subscribers: tberghammer, sas, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16004
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257502
should perform loop interchanges itself.
This also fixes a bug we see due to the "loop-interchange" pass producing
incorrect IR when compiling linpack-pc.c from the LLVM test-suite with
"-polly-position=before-vectorizer".
Reviewed-by: Tobias Grosser <tobias@grosser.es>
llvm-svn: 257495
The findExternalCalls routine ignores calls to functions already
defined in the dest module. This was not handling the case where
the definition in the current module is actually an alias to a
function call.
llvm-svn: 257493
MIPS _gp_disp designates offset between start of function and gp pointer
into GOT therefore any relocations against it do not require dynamic
relocation.
llvm-svn: 257492
This is a very limited implementation of DFG-based copy propagation.
It only handles actual COPY instructions (does not handle other equivalents
such as add-immediate with a 0 operand).
The major limitation is that it does not update the DFG: that will be the
change required to make it more robust (hopefully coming up soon).
llvm-svn: 257490
This new API, int kmp_set_thread_affinity_mask_initial(), is available for use
by other parallel runtime libraries inside a possibly OpenMP-registered thread.
This entry point restores the current thread's affinity mask to the affinity
mask of the application when it first began. If -1 is returned it can be assumed
that either the thread hasn't called affinity initialization or that the thread
isn't registered with the OpenMP library. If 0 is returned then, then the call
was successful. Any return value greater than zero indicates an error occurred
when setting affinity.
Differential Revision: http://reviews.llvm.org/D15867
llvm-svn: 257489
Prepatory patch before changing LibCallSimplifier to use the FMF.
Also, tighten the CHECK lines and give the tests more meaningful names.
Similar changes to:
http://reviews.llvm.org/rL257414
llvm-svn: 257481
This patch removes the requirement on stable-runtime on insertvalue_origin.cc
testcase, added due a instrumentation failure on aarch64-linux. This is fixed
on llvm code by r257375.
llvm-svn: 257479
Summary: The result register is the second operand as per the other mt* instructions.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D15993
llvm-svn: 257478
Target independent, SSA-based data flow framework for representing
data flow between physical registers.
This commit implements the creation of the actual data flow graph.
llvm-svn: 257477
Summary:
This fixes three bugs, in all of which state is not or incorrecly reset between
objects (i.e. when reusing the same pass manager to create multiple object
files):
1) AttributeSection needs to be reset to nullptr, because otherwise the backend
will try to emit into the old object file's attribute section causing a
segmentation fault.
2) MappingSymbolCounter needs to be reset, otherwise the second object file
will start where the first one left off.
3) The MCStreamer base class resets the Streamer's e_flags settings. Since
EF_ARM_EABI_VER5 is set on streamer creation, we need to set it again
after the MCStreamer was rest.
Also rename Reset (uppser case) to EHReset to avoid confusion with
reset (lower case).
Reviewers: rengolin
Differential Revision: http://reviews.llvm.org/D15950
llvm-svn: 257473
On Windows different versions of 'sed' work in different text/binary
mode by default. If default mode is text, sed produces corrupted binary
files. Unfortunately there is no standard command line option to select
the mode. Some 'sed' support '-b' to switch to binary mode, while other
ones support '--text' option and does not have '-b' option at all.
llvm-svn: 257471
(64 to 128-bit) matches against the pattern fragment 'vzmovl_v2i64'
(a zero-extended 64-bit load).
However, a change in r248784 teaches the instruction combiner that only
the lower 64 bits of the input to a 128-bit vcvtph2ps are used. This means
the instruction combiner will ordinarily optimize away the upper 64-bit
insertelement instruction in the zero-extension and so we no longer select
the memory-register form. To fix this a new pattern has been added.
Differential Revision: http://reviews.llvm.org/D16067
llvm-svn: 257470
Will re-apply after llvm 3.8 is branched.
Original commit message:
Driver: fallback to the location of clang if no sysroot,
hard coding /usr makes little sense for mingw-w64.
If we have portable toolchains having /usr breaks that.
If the clang we use is in /usr/bin or /usr/sbin etc this will
still detect as though it was hard coded to /usr
This makes the most sense going forward for mingw-w64 toolchains
on both linux and mac
llvm-svn: 257468
This fix a bug in RangeSet::pin causing single value ranges to be considered non conventionally ordered.
Differential Revision: http://reviews.llvm.org/D12901
llvm-svn: 257467
Hans Wennborg