memory, rather than representing the stubs in IR. Update the CompileOnDemand
layer to use this functionality.
Directly emitting stubs is much cheaper than building them in IR and codegen'ing
them (see below). It also plays well with remote JITing - stubs can be emitted
directly in the target process, rather than having to send them over the wire.
The downsides are:
(1) Care must be taken when resolving symbols, as stub symbols are held in a
separate symbol table. This is only a problem for layer writers and other
people using this API directly. The CompileOnDemand layer hides this detail.
(2) Aliases of function stubs can't be symbolic any more (since there's no
symbol definition in IR), but must be converted into a constant pointer
expression. This means that modules containing aliases of stubs cannot be
cached. In practice this is unlikely to be a problem: There's no benefit to
caching such a module anyway.
On balance I think the extra performance is more than worth the trade-offs: In a
simple stress test with 10000 dummy functions requiring stubs and a single
executed "hello world" main function, directly emitting stubs reduced user time
for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct
emission).
llvm-svn: 250712
The reason of collecting all undefines in vector is that during reading files we already need to have Symtab created. Or like was done in that patch - to put undefines from scripts somewhere to delay Symtab.addUndefinedOpt() call.
Differential Revision: http://reviews.llvm.org/D13870
llvm-svn: 250711
Even though these are under examples/, they actually get loaded
when LLDB starts up during initialization of ScriptInterpreterPython.
There's obviously some kind of layering issue here (and comments
in the code even point to that as well), but for now just make them
py3 compatible.
llvm-svn: 250710
Newer versions of CMake include a "smarter" FindLibxml2 package.
In theory this is a good thing, but on Windows it's now smart
enough to find the version that comes with Gnuwin32, which doesn't
appear to be a valid libxml2 distribution. Or at the very least,
LLDB currently uses some header files from libxml2 that are not
part of this distribution.
Nobody on Windows is using any of this functionality right now
anyway, so just disable it.
llvm-svn: 250709
warnings similar to the following:
runtime/src/kmp_global.c:117:35: warning: implicit conversion from
'unsigned long' to 'int' changes value from 18446744073709551615 to -1
[-Wconstant-conversion]
int __kmp_sys_max_nth = KMP_MAX_NTH;
~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~
runtime/src/kmp.h:849:34: note: expanded from macro 'KMP_MAX_NTH'
# define KMP_MAX_NTH PTHREAD_THREADS_MAX
^~~~~~~~~~~~~~~~~~~
Clamp KMP_MAX_NTH to INT_MAX to avoid these warnings. Also use INT_MAX
whenever PTHREAD_THREADS_MAX is not defined at all.
Differential Revision: http://reviews.llvm.org/D13827
llvm-svn: 250708
This makes the format tests look more like most other FileCheck tests in clang.
The multiple-inputs tests still use temp files, to make sure that the file
input code in clang-format stays tested.
Stop stripping out the comment lines in style-on-command-line.cpp as they don't
get in the way and it makes the test simpler. Also remove 2>&1s on the tests in
that file that don't need it.
http://reviews.llvm.org/D13852
llvm-svn: 250706
This patch corrects the number of bytes of debug register resources which are written while installing or removing a breakpoint using ptrace interface on arm64 targets.
Differential revision: http://reviews.llvm.org/D12522
llvm-svn: 250700
Summary:
This patch adds support to llvm-lto that mirrors the support added by
r249270 to the gold plugin. This enables better testing of combined
index generation for ThinLTO.
Added a new test, and this support will be used in the test in D13515.
Reviewers: joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13847
llvm-svn: 250699
The mapping of these two intrinsics in ARMInstrInfo.td had a small
omission which lead to their operands not being validated/transformed
before being lowered into usat and ssat instructions. This can cause
incorrect instructions to be emitted.
I've also added tests for the remaining two saturating arithmatic
intrinsics @llvm.arm.qadd and @llvm.arm.qsub as they are missing
codegen tests.
llvm-svn: 250697
For o32 applications on mips we were getting segmentation fault while launching lldb-server because of overwritting stack when using elf_gregset_t in DoWriteRegisterValue.
We are now using the GPR_mips_linux buffer in DoWriteRegisterValue as done in DoReadRegisterValue also, which solves the above issue.
llvm-svn: 250696
New values were always synthesized in the block of the instruction
that needed them. This is incorrect for PHI node whose' value must be
defined in the respective incoming block. This patch temporarily moves
the builder's insert point to the incoming block while synthesizing phi
node arguments.
This fixes PR25241 (http://llvm.org/bugs/show_bug.cgi?id=25241)
llvm-svn: 250693
We were keeping a reference to an object in a DenseMap then mutating it. At the end of the function we were attempting to clone that reference into other keys in the DenseMap, but DenseMap may well decide to resize its hashtable which would invalidate the reference!
It took an extremely complex testcase to catch this - many thanks to Zhendong Su for catching it in PR25225.
This fixes PR25225.
llvm-svn: 250692
The Intel MCU psABI requires floating-point values to be passed in-reg.
This makes the x86-32 ABI code respect "-mfloat-abi soft" and generate float inreg arguments.
Differential Revision: http://reviews.llvm.org/D13554
llvm-svn: 250689
Originally I planned to use the same interface for masked gather/scatter and set isConsecutive to "false" in this case.
Now I'm implementing masked gather/scatter and see that the interface is inconvenient. I want to add interfaces isLegalMaskedGather() / isLegalMaskedScatter() instead of using the "Consecutive" parameter in the existing interfaces.
Differential Revision: http://reviews.llvm.org/D13850
llvm-svn: 250686
Since the attribute documentation is now auto-generated, the previous references
are no longer valid. This prevented the docs build from completing
successfully.
llvm-svn: 250674
Python requires that Python.h is included before any std header. Not doing so
results in conflicts with standards macros such as `_XOPEN_SOURCE`. NFC.
llvm-svn: 250673
-assume-filename, -fallback-style, and -sort-includes are new. (They're also
longer than the previous options, so all descriptions shift over by some amount,
making this diff look larger than it is.)
It looks like someone renamed "General options" to "Generic Options" too.
llvm-svn: 250672
If no arguments are specified, it formats the code from standard input
and writes the result to the standard output.
If <file>s are given, it reformats the files. If -i is specified
together with <file>s, the files are edited in-place. Otherwise, the
result is written to the standard output.
USAGE: clang-format [options] [<file> ...]
OPTIONS:
-assume-filename=<string> - When reading from stdin, clang-format assumes this
filename to look for a style config file (with
-style=file) and to determine the language.
-cursor=<uint> - The position of the cursor when invoking
clang-format from an editor integration
-dump-config - Dump configuration options to stdout and exit.
Can be used with -style option.
-fallback-style=<string> - The name of the predefined style used as a
fallback in case clang-format is invoked with
-style=file, but can not find the .clang-format
file to use.
Use -fallback-style=none to skip formatting.
-help - Display available options (-help-hidden for more)
-i - Inplace edit <file>s, if specified.
-length=<uint> - Format a range of this length (in bytes).
Multiple ranges can be formatted by specifying
several -offset and -length pairs.
When only a single -offset is specified without
-length, clang-format will format up to the end
of the file.
Can only be used with one input file.
-lines=<string> - <start line>:<end line> - format a range of
lines (both 1-based).
Multiple ranges can be formatted by specifying
several -lines arguments.
Can't be used with -offset and -length.
Can only be used with one input file.
-offset=<uint> - Format a range starting at this byte offset.
Multiple ranges can be formatted by specifying
several -offset and -length pairs.
Can only be used with one input file.
-output-replacements-xml - Output replacements as XML.
-sort-includes - Sort touched include lines
-style=<string> - Coding style, currently supports:
LLVM, Google, Chromium, Mozilla, WebKit.
Use -style=file to load style configuration from
.clang-format file located in one of the parent
directories of the source file (or current
directory for stdin).
Use -style="{key: value, ...}" to set specific
parameters, e.g.:
-style="{BasedOnStyle: llvm, IndentWidth: 8}"
-version - Display the version of this program output.
llvm-svn: 250671
There are several different kinds of constants that could occur in a
branch condition, however we can only handle the most interesting one
namely constant integers. To this end we have to treat others as
non-affine.
This fixes bug 25244.
llvm-svn: 250669
We build the schedule based on a traversal of the region and accumulate
information for each loop in it. The total schedule is associated with the
loop surrounding the SCoP, though it can happen that there are blocks in the
SCoP which are part of loops that are only partially in the SCoP. Instead of
associating information with them (they are not part of the SCoP and
consequently are not modeled) we have to associate the schedule information
with the surrounding loop if any.
This fixes bug 25240.
llvm-svn: 250668
Accesses that have a relative offset (in bytes) that is not divisible
by the type size (in bytes) will be represented as empty in the SCoP
description. This is on its own not good but it also crashed the
invariant load hoisting. This patch will fix the latter problem while
the former should be addressed too.
This fixes bug 25236.
llvm-svn: 250664
If the base pointer of a load is invariant and defined in the SCoP but
not loaded we cannot hoist the load as we would not hoist the base
pointer definition.
This fixes bug 25237.
llvm-svn: 250663
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662