| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Right now it only contains the LinkageType, but will be extended
with "hasSection", "isOptSize", "hasInlineAssembly", etc.
Differential Revision: http://reviews.llvm.org/D19404
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267319
|
| |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19456
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267318
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Keeping as much as possible internal/private is
known to help the optimizer. Let's try to benefit from
this in ThinLTO.
Note: this is early work, but is enough to build clang (and
all the LLVM tools). I still need to write some lit-tests...
Differential Revision: http://reviews.llvm.org/D19103
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267317
|
| |
|
|
| |
llvm-svn: 267316
|
| |
|
|
| |
llvm-svn: 267315
|
| |
|
|
|
|
|
|
|
| |
Fixes check-llvm when bootstrapping.
Also remove mostly dead and most likely incorrect logic regarding preemption
of weak undefined symbols.
llvm-svn: 267314
|
| |
|
|
|
|
| |
the string is just true or 1.
llvm-svn: 267313
|
| |
|
|
|
|
| |
text string which always evaluates to true. Add a ! so they'll evaluate to false.
llvm-svn: 267312
|
| |
|
|
|
|
| |
instructions. Only one of the conditions should be valid for each pattern, not both. Update tests accordingly.
llvm-svn: 267311
|
| |
|
|
|
|
| |
Now that the support for the 'new' relocations is available.
llvm-svn: 267310
|
| |
|
|
| |
llvm-svn: 267309
|
| |
|
|
|
|
| |
Add a case where we can't relax.
llvm-svn: 267308
|
| |
|
|
|
|
|
|
|
| |
The option to control the emission of the new relocations
is -relax-relocations (blatantly copied from GNU as).
It can't be enabled by default because it breaks relatively
recent versions of ld.bfd/ld.gold (late 2015).
llvm-svn: 267307
|
| |
|
|
|
|
|
|
| |
It seems we still have some ordering issue in the combined index
emission, but I can't figure out why right now.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267306
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fixup for r267304.
The test was sensitive to the path in a subtle way:
the index in memory is sorted by GUID, which are hashes
that include the source filename for local globals.
Teresa recently added a directive at the IR level, so
we can specify it here to make the test independent of
the path.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed in D18298, some local globals can't
be renamed/promoted (because they have a section, or because
they are referenced from inline assembly).
To be able to detect naming collision, we need to keep around
the "GUID" using their original name without taking the linkage
into account.
Reviewers: tejohnson
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D19454
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We are always importing the initializer for a GlobalVariable.
So if a GlobalVariable is in the export-list, we pull in any
refs as well.
Reviewers: tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19102
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267303
|
| |
|
|
|
|
| |
Update testcases due to DIBuilder change.
llvm-svn: 267302
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A long overdue change to make DIGlobalVariable distinct. Much like
DISubprogram definitions (changed in r246098), it isn't logical to
unique DIGlobalVariable definitions from two different compile units.
(Longer-term, we should also find a way to reverse the link between
GlobalVariable and DIGlobalVariable, and between DIGlobalVariable and
DICompileUnit, so that debug info to do with optimized-out globals
disappears. Admittedly it's harder than with Function/DISubprogram,
since global variables may be constant-folded and the debug info should
still describe that somehow.)
llvm-svn: 267301
|
| |
|
|
|
|
| |
In preparation for other changes.
llvm-svn: 267300
|
| |
|
|
|
|
|
|
|
|
| |
r267298 didn't quite fix the build errors. Use SmallVector instead of
std::vector, the latter of which I think is trying to maintain a strong
exception safety guarantee.
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/6228
llvm-svn: 267299
|
| |
|
|
|
|
|
|
|
| |
Not exactly sure why the host tries to use a copy constructor here, but
it's easy enough to work around it.
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/6227
llvm-svn: 267298
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM stopped using MDString-based type references, and DIBuilder no
longer fills 'retainedTypes:' with every DICompositeType that has an
'identifier:' field. There are just minor changes to keep the same
behaviour in CFE.
Leaving 'retainedTypes:' unfilled has a dramatic impact on the output
order of the IR though. There are a huge number of testcase changes,
which were unfortunately not really scriptable.
llvm-svn: 267297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around
DIType*. It is no longer legal to refer to a DICompositeType by its
'identifier:', and DIBuilder no longer retains all types with an
'identifier:' automatically.
Aside from the bitcode upgrade, this is mainly removing logic to resolve
an MDString-based reference to an actualy DIType. The commits leading
up to this have made the implicit type map in DICompileUnit's
'retainedTypes:' field superfluous.
This does not remove DITypeRef, DIScopeRef, DINodeRef, and
DITypeRefArray, or stop using them in DI-related metadata. Although as
of this commit they aren't serving a useful purpose, there are patchces
under review to reuse them for CodeView support.
The tests in LLVM were updated with deref-typerefs.sh, which is attached
to the thread "[RFC] Lazy-loading of debug info metadata":
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html
llvm-svn: 267296
|
| |
|
|
|
|
| |
BranchInst member function; NFCI
llvm-svn: 267295
|
| |
|
|
|
|
| |
This reverts commit r267206, as it broke self-hosting on AArch64.
llvm-svn: 267294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds libc interceptors to the runtime library for the new
EfficiencySanitizer ("esan") family of tools. The interceptors cover
the memory operations in most common library calls and will be shared
among all esan tools.
Reviewers: aizatsky
Subscribers: zhaoqin, tberghammer, danalbert, srhines, llvm-commits, vitalybuka, eugenis, kcc
Differential Revision: http://reviews.llvm.org/D19411
llvm-svn: 267293
|
| |
|
|
| |
llvm-svn: 267292
|
| |
|
|
|
|
|
|
| |
This adds basic parsing of the EABI attributes section. This section contains
additional information about the target for which the file was built. Attempt
to infer additional architecture information from that section.
llvm-svn: 267291
|
| |
|
|
|
|
| |
raw_string_ostream::str() to flush the buffer explicitly.
llvm-svn: 267290
|
| |
|
|
|
|
|
|
|
| |
Memory accesses can have non-precisely modeled access functions that
would cause us to build incorrect execution context for hoisted loads.
This is the same issue that occurred during the domain construction for
statements and it is dealt with the same way.
llvm-svn: 267289
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The SCEVAffinator will now produce not only the isl representaiton of
a SCEV but also the domain under which it is invalid. This is used to
record possible overflows that can happen in the statement domains in
the statements invalid domain. The result is that invalid loads have
an accurate execution contexts with regards to the validity of their
statements domain. While the SCEVAffinator currently is only taking
"no-wrapping" assumptions, we can add more withouth worrying about the
execution context of loads that are optimistically hoisted.
llvm-svn: 267288
|
| |
|
|
|
|
| |
Thanks to STL for the catch
llvm-svn: 267287
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The invalid context is not enough to describe the parameter constraints under
which a statement is not modeled precisely. The reason is that during the
domain construction the bounds on the induction variables are not known but
needed to check if e.g., an overflow can actually happen. To this end we
replace the invalid context of a statement with an invalid domain. It is
initialized during domain construction and intersected with the domain once
it was completely build. Later this invalid domain allows to eliminate
falsely assumed wrapping cases and other falsely assumed mismatches in the
modeling.
llvm-svn: 267286
|
| |
|
|
|
|
|
| |
If the AssumptionContext is a subset of the InvalidContext the runtime
context is not feasible.
llvm-svn: 267285
|
| |
|
|
|
|
|
| |
If we know it is safe to execute a load we do not need an execution
context, however only if we are sure it was modeled correctly.
llvm-svn: 267284
|
| |
|
|
|
|
|
| |
These calls were sometimes costly and do not show any improvements on our
small test cases.
llvm-svn: 267283
|
| |
|
|
|
|
| |
Currently failing due to poor blend matching, found whilst investigating PR27472
llvm-svn: 267282
|
| |
|
|
|
|
| |
%T expands to Output if not configured differently.
llvm-svn: 267281
|
| |
|
|
|
|
| |
select to detect if the input is zero to return the original size instead of the extended size. Instead just set the first bit in the zero extended part.
llvm-svn: 267280
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes a couple of flags added to control this behavior, and
simply keeps all value names when save-temps is specified.
Reviewers: rafael
Subscribers: llvm-commits, pcc, davide
Differential Revision: http://reviews.llvm.org/D19384
llvm-svn: 267279
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.
Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references. In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled. This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).
Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves. Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).
I've added two testcases:
- test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
instead of uniqued ones. This confirms that, in the absence of
uniqued nodes, distinct nodes are still emitted in post-order.
- test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
example where a naive post-order traversal would cause one uniqued
node to forward-reference another. IOW, it's the motivating test.
llvm-svn: 267278
|
| |
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11700
llvm-svn: 267277
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an operand of a distinct node hasn't been read yet, the reader can
use a DistinctMDOperandPlaceholder. This is much cheaper than forward
referencing from a uniqued node. Change
ValueEnumerator::organizeMetadata to partition distinct nodes and
uniqued nodes to reduce the overhead of cycles broken by distinct nodes.
Mehdi measured this for me; this removes most of the RAUW from the
importing step of -flto=thin, even after a WIP patch that removes
string-based DITypeRefs (introducing many more cycles to the metadata
graph).
llvm-svn: 267276
|
| |
|
|
|
|
| |
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36076
llvm-svn: 267275
|
| |
|
|
| |
llvm-svn: 267274
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed in on the mailing list yesterday, I have refactored
BitcodeWriter.cpp to use classes to manage the bitcode writing process,
instead of passing around long lists of parameters between static
functions. See:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098610.html
I created a parent BitcodeWriter class to own the BitstreamWriter,
write the header, and contain the main entry point into the writing
process. There are two derived classes, one for writing a module and one
for writing a combined index file (for ThinLTO), which manage the
writing process specific to those bitcode file types.
I also changed the functions to conform to LLVM coding standards
(lowercase function name first letter). The only two routines that still
start with an uppercase letter are the two external interfaces, which
can be fixed as a follow-on (I wanted to keep this round just within
BitcodeWriter.cpp).
Reviewers: dexonsmith, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19447
llvm-svn: 267273
|
| |
|
|
|
|
| |
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36074
llvm-svn: 267272
|
| |
|
|
|
|
|
|
| |
Mehdi's pattern recognition pulled this one out. This is cleaner with
std::find_if than with the strange helper function that took an iterator
by reference and updated it.
llvm-svn: 267271
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each reference to an unresolved MDNode is expensive, since the RAUW
support in MDNode uses a separate allocation and side map. Since
a distinct MDNode doesn't require its operands on creation (unlike
uniuqed nodes, there's no need to check for structural equivalence),
use nullptr for any of its unresolved operands. Besides reducing the
burden on MDNode maps, this can avoid allocating temporary MDNodes in
the first place.
We need some way to track operands. Invent DistinctMDOperandPlaceholder
for this purpose, which is a Metadata subclass that holds an ID and
points at its single user. DistinctMDOperandPlaceholder::replaceUseWith
is just like RAUW, but its name highlights that there is only ever
exactly one use.
There is no support for moving (or, obviously, copying) these. Move
support would be possible but expensive; leaving it unimplemented
prevents user error. In the BitcodeReader I originally considered
allocating on a BumpPtrAllocator and keeping a vector of pointers to
them, and then I realized that std::deque implements exactly this.
A couple of obvious follow-ups:
- Change ValueEnumerator to emit distinct nodes first to take more
advantage of this optimization. (How convenient... I think I might
have a couple of patches for this.)
- Change DIBuilder and its consumers (like CGDebugInfo in clang) to
use something like this when constructing debug info in the first
place.
llvm-svn: 267270
|