Having different code paths for streamed and regular bitcode reading was a
source of bugs in the past and this defines them away.
It has a small but noticeable impact on performance. I timed running
"opt -disable-output -disable-verify" on a ltoed clang. It goes from
14.752845231 seconds time elapsed ( +- 0.16% )
to
15.012463721 seconds time elapsed ( +- 0.11% )
Extracted from a patch by Karl Schimpf.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240305 91177308-0d34-0410-b5e6-96231b3b80d8
Now that pr23900 is fixed, we can bring it back with no changes.
Original message:
Make all temporary symbols unnamed.
What this does is make all symbols that would otherwise start with a .L
(or L on MachO) unnamed.
Some of these symbols still show up in the symbol table, but we can just
make them unnamed.
In order to make sure we produce identical results when going thought assembly,
all .L (not just the compiler produced ones), are now unnamed.
Running llc on llvm-as.opt.bc, the peak memory usage goes from 208.24MB to
205.57MB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240302 91177308-0d34-0410-b5e6-96231b3b80d8
Before this we were producing a TargetExternalSymbol from a MCSymbol.
That meant extracting the symbol name and fetching the symbol again
down the pipeline.
This patch adds a DAG.getMCSymbol that lets the MCSymbol pass unchanged on the
DAG.
Doing so removes the need for MO_NOPREFIX and fixes the root cause of pr23900,
allowing r240130 to be committed again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240300 91177308-0d34-0410-b5e6-96231b3b80d8
This commit implements initial machine instruction serialization. It
serializes machine instruction names. The instructions are represented
using a YAML sequence of string literals and are a part of machine
basic block YAML mapping.
This commit introduces a class called 'MIParser' which will be used to
parse the machine instructions and operands.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10481
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240295 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The code responsible for shl folding in the DAGCombiner was assuming incorrectly that all constants are less than 64 bits. This patch simply changes the way values are compared.
Test Plan: A regression test included.
Reviewers: andreadb
Reviewed By: andreadb
Subscribers: andreadb, test, llvm-commits
Differential Revision: http://reviews.llvm.org/D10602
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240291 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is an implementation of RuntimeDyld::SymbolResolver that simply
rejects all resolution requests; useful for clients that do not have any
cross-object symbol references.
Reviewers: lhames
Reviewed By: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10455
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240288 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: In this case, we're supposed to load the immediate in AT and then ADDu it with the source register and put it in the destination register.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9367
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240278 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In this case, we're supposed to load the address of the symbol in AT and then ADDu it with the source register and
put it in the destination register.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240273 91177308-0d34-0410-b5e6-96231b3b80d8
This allows more call sequences to use pushes instead of movs when optimizing for size.
In particular, calling conventions that pass some parameters in registers (e.g. thiscall) are now supported.
Differential Revision: http://reviews.llvm.org/D10500
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240257 91177308-0d34-0410-b5e6-96231b3b80d8
This will allow classes to implement the AA interface without deriving
from the class or referencing an internal enum of some other class as
their return types.
Also, to a pretty fundamental extent, concepts such as 'NoAlias',
'MayAlias', and 'MustAlias' are first class concepts in LLVM and we
aren't saving anything by scoping them heavily.
My mild preference would have been to use a scoped enum, but that
feature is essentially completely broken AFAICT. I'm extremely
disappointed. For example, we cannot through any reasonable[1] means
construct an enum class (or analog) which has scoped names but converts
to a boolean in order to test for the possibility of aliasing.
[1]: Richard Smith came up with a "solution", but it requires class
templates, and lots of boilerplate setting up the enumeration multiple
times. Something like Boost.PP could potentially bundle this up, but
even that would be quite painful and it doesn't seem realistically worth
it. The enum class solution would probably work without the need for
a bool conversion.
Differential Revision: http://reviews.llvm.org/D10495
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240255 91177308-0d34-0410-b5e6-96231b3b80d8
accurately describe what is being tracked.
While these two enums do track mod/ref information and aliasing
information, they don't represent the exact same things as either the
mod/ref enums or the alias result enum in AA. They're definitions are
dominated by the structure of their lattice and the bit's various
semantics. This patch just calls them what they are and tries to spell
out usefully distinct names for these things.
This will clear the path for using a raw unscoped enum to represent some
of these concepts across LLVM's analysis library.
No functionality changed here.
Differential Revision: http://reviews.llvm.org/D10494
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240254 91177308-0d34-0410-b5e6-96231b3b80d8
If we don't know how to represent a .debug_loc entry, skip the entry
entirely rather than emitting an empty one. Similarly, if a .debug_loc
list has no entries, don't create the list.
We still want to create the variables, just in an optimized-out form
that doesn't have a DW_AT_location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240244 91177308-0d34-0410-b5e6-96231b3b80d8
There are three types of `DbgVariable`:
- alloca variables, created based on the MMI table,
- register variables, created based on DBG_VALUE instructions, and
- optimized-out variables.
This commit reconfigures `DbgVariable` to make it easier to tell which
kind we have, and make initialization a little clearer.
For MMI/alloca variables, `FrameIndex.size()` must always equal
`Expr.size()`, and there shouldn't be an `MInsn`. For register
variables (with a `MInsn`), `FrameIndex` must be empty, and `Expr`
should have 0 or 1 element depending on whether it has a complex
expression (registers with multiple locations use `DebugLocListIndex`).
Optimized-out variables shouldn't have any of these fields.
Moreover, this separates DBG_VALUE initialization until after the
variable is created, simplifying logic in a future commit that changes
`collectVariableInfo()` to stop creating empty .debug_loc entries/lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240243 91177308-0d34-0410-b5e6-96231b3b80d8
Sparse switches with profile info are lowered as weight-balanced BSTs. For
example, if the node weights are {1,1,1,1,1,1000}, the right-most node would
end up in a tree by itself, bringing it closer to the top.
However, a leaf in this BST can contain up to 3 cases, and having a single
case in a leaf node as in the example means the tree might become
unnecessarily high.
This patch adds a heauristic to the pivot selection algorithm that moves more
cases into leaf nodes unless that would lower their rank. It still doesn't
yield the optimal tree in every case, but I believe it's conservatibely correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240224 91177308-0d34-0410-b5e6-96231b3b80d8
Calling operator* on a WeakVH whose Value is null hits undefined
behaviour, since we bind the value to a reference. Instead, go through
`operator Value*` so that we work with the pointer itself.
Found by ubsan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240214 91177308-0d34-0410-b5e6-96231b3b80d8
Seems like MSVC doesn't like this:
InstrProf.h(49) : error C2614: 'llvm::InstrProfRecord' : illegal member initialization: 'Hash' is not a base or member
This reverts r240206.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240208 91177308-0d34-0410-b5e6-96231b3b80d8
This consolidates the logic to read instrprof records into the on disk
hash table's lookup trait and makes us copy the counter data instead
of taking references to it as we read. This will simplify further
changes to the format.
Patch by Betul Buyukkurt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240206 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This adds FindGlobalVariableNamed to ExecutionEngine
(plus implementation in MCJIT), which is an analog of
FindFunctionNamed for GlobalVariables.
Reviewers: lhames
Reviewed By: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10421
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240202 91177308-0d34-0410-b5e6-96231b3b80d8
When a case of INT64_MIN was followed by a case that was greater than
zero, we were overflowing a signed integer here. Since we've sorted
the cases here anyway (and thus currentValue must be greater than
nextValue) it's simple enough to avoid this by using addition rather
than subtraction.
Found by UBSAN on existing tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240201 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Since FunctionMap has llvm::Function pointers as keys, the order in
which the traversal happens can differ from run to run, causing spurious
FileCheck failures. Have CallGraph::print sort the CallGraphNodes by
name before printing them.
Reviewers: bogner, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10575
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240191 91177308-0d34-0410-b5e6-96231b3b80d8
If LLVMDebugInfoPDB links against the DIA SDK then the exports file
would contain an INTERFACE_LINK_LIBRARIES property that contained an
absolute path to ``diaguids.lib`` which used a native windows path (interpreted
as escape sequences when LLVMExports.cmake is imported causing
``find_package(LLVM)`` to fail) rather than the correct CMake style path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240181 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes getRelocationAddend to use ErrorOr and considers it an error
to try to get the addend of a REL section.
If, for example, a x86_64 file has a REL section, that file is corrupted and
we should reject it.
Using ErrorOr is not ideal since we check the section type once per relocation
instead of once per section.
Checking once per section would involve getRelocationAddend just asserting and
callers checking the section before iterating over the relocations.
In any case, this is an improvement and includes a test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240176 91177308-0d34-0410-b5e6-96231b3b80d8
The ADDITIONAL_HEADER_DIRS command can be used to tell UIs that a given library
owns certain headers. The path for MCParser was missing MC/ in it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240175 91177308-0d34-0410-b5e6-96231b3b80d8
This commit reports an error when the MIR parser can't find
a basic block with the machine basic block's name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240174 91177308-0d34-0410-b5e6-96231b3b80d8
There are 3 types of relocations on MachO
* Scattered
* Section based
* Symbol based
On ELF and COFF relocations are symbol based.
We were in the strange situation that we abstracted over two of them. This makes
section based relocations MachO only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240149 91177308-0d34-0410-b5e6-96231b3b80d8
This commit implements the initial serialization of machine basic blocks in a
machine function. Only the simple, scalar MBB attributes are serialized. The
reference to LLVM IR's basic block is preserved when that basic block has a name.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10465
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240145 91177308-0d34-0410-b5e6-96231b3b80d8
