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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267273 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267271 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267270 91177308-0d34-0410-b5e6-96231b3b80d8
Consistently use the IsDistinct variable and start relying on it in
GET_OR_DISTINCT. This change has NFC, but prepares for using IsDistinct
to optimize the behaviour of the getMD() and getMDOrNull() helpers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267268 91177308-0d34-0410-b5e6-96231b3b80d8
The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) that is
already caught by Verifier::visitDILocation. The Verifier is a better
place for this anyway, and being inconsistent with other subclasses of
MDNode isn't serving anyone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267267 91177308-0d34-0410-b5e6-96231b3b80d8
Re-layer the functions in the new (i.e., newly correct) post-order
traversals in ValueEnumerator (r266947) and ValueMapper (r266949).
Instead of adding a node to the worklist in a helper function and
returning a flag to say what happened, return the node itself. This
makes the code way cleaner: the worklist is local to the main function,
there is no flag for an early loop exit (since we can cleanly bury the
loop), and it's perfectly clear when pointers into the worklist might be
invalidated.
I'm fixing both algorithms in the same commit to avoid repeating the
commit message; if you take the time to understand one the other should
be easy. The diff itself isn't entirely obvious since the traversals
have some noise (i.e., things to do), but here's the high-level change:
auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) {
=> while (I != E) {
if (shouldVisit(Op)) { T *Op = *I++;
WL.push(Op, Op->begin()); if (shouldVisit(Op)) {
return true; return Op;
} }
return false; return nullptr;
}; };
=>
WL.push(S, S->begin()); WL.push(S, S->begin());
while (!empty()) { while (!empty()) {
auto *N = WL.top().N; auto *N = WL.top().N;
auto *&I = WL.top().I; auto *&I = WL.top().I;
bool DidChange = false;
while (I != N->end())
if (helper(*I++)) { => if (T *Op = helper(I, N->end()) {
DidChange = true; WL.push(Op, Op->begin());
break; continue;
} }
if (DidChange)
continue;
POT.push(WL.pop()); => POT.push(WL.pop());
} }
Thanks to Mehdi for helping me find a better way to layer this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267099 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the interfaces added (and not yet complete) to support
lazy reading of summaries. This support is not expected to be needed
since we are moving to a model where the full index is only being
traversed in the thin link step, instead of the back ends.
(The second part of this that I plan to do next is remove the
GlobalValueInfo from the ModuleSummaryIndex - it was mostly needed to
support lazy parsing of summaries. The index can instead reference the
summary structures directly.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267097 91177308-0d34-0410-b5e6-96231b3b80d8
Emit metadata nodes in post-order. The iterative algorithm from r266709
failed to maintain this property. After understanding my mistake, it
wasn't too hard to write a test with llvm-bcanalyzer (and I've actually
made this change once before: see r220340).
This also reverts the "noisy" testcase change from r266709. That should
have been more of a red flag :/.
Note: The same bug crept into the ValueMapper in r265456. I'm still
working on the fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266947 91177308-0d34-0410-b5e6-96231b3b80d8
Don't use std::vector<TrackingMDRef>, since (at least in some versions
of libc++) std::vector apparently copies values on grow operations
instead of moving them. Found this when I was temporarily deleting the
copy constructor for TrackingMDRef to investigate a performance
bottleneck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266909 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch prevents importing from (and therefore exporting from) any
module with a "llvm.used" local value. Local values need to be promoted
and renamed when importing, and their presense on the llvm.used variable
indicates that there are opaque uses that won't see the rename. One such
example is a use in inline assembly.
See also the discussion at:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098047.html
As part of this, move collectUsedGlobalVariables out of Transforms/Utils
and into IR/Module so that it can be used more widely. There are several
other places in LLVM that used copies of this code that can be cleaned
up as a follow on NFC patch.
Reviewers: joker.eph
Subscribers: pcc, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18986
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266877 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new method, DICompositeType::buildODRType, that will create or
mutate the DICompositeType for a given ODR identifier, and use it in
LLParser and BitcodeReader instead of DICompositeType::getODRType.
The logic is as follows:
- If there's no node, create one with the given arguments.
- Else, if the current node is a forward declaration and the new
arguments would create a definition, mutate the node to match the
new arguments.
- Else, return the old node.
This adds a missing feature supported by the current DITypeIdentifierMap
(which I'm slowly making redudant). The only remaining difference is
that the DITypeIdentifierMap has a "the-last-one-wins" rule, whereas
DICompositeType::buildODRType has a "the-first-one-wins" rule.
For now I'm leaving behind DICompositeType::getODRType since it has
obvious, low-level semantics that are convenient for unit testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266786 91177308-0d34-0410-b5e6-96231b3b80d8
Lift the API for debug info ODR type uniquing up a layer. Instead of
clients managing the map directly on the LLVMContext, add a static
method to DICompositeType called getODRType and handle the map in the
background. Also adds DICompositeType::getODRTypeIfExists, so far just
for convenience in the unit tests.
This simplifies the logic in LLParser and BitcodeReader. Because of
argument spam there are actually a few more lines of code now; I'll see
if I come up with a reasonable way to clean that up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266742 91177308-0d34-0410-b5e6-96231b3b80d8
Tighten up the API for debug info ODR type uniquing in LLVMContext. The
only reason to allow other DIType subclasses is to make the unit tests
prettier :/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266737 91177308-0d34-0410-b5e6-96231b3b80d8
As per David's review, rename everything in the new API for ODR type
uniquing of debug info.
ensureDITypeMap => enableDebugTypeODRUniquing
destroyDITypeMap => disableDebugTypeODRUniquing
hasDITypeMap => isODRUniquingDebugTypes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266713 91177308-0d34-0410-b5e6-96231b3b80d8
Use a worklist instead of recursing through MDNode operands in
ValueEnumerator. The actual record output order has changed slightly,
but otherwise there's no functionality change.
I had to update test/Bitcode/metadata-function-blocks.ll. I renumbered
nodes so they continue to match the implicit record ids.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266709 91177308-0d34-0410-b5e6-96231b3b80d8
I have no idea how I chose two different spellings in the space of a
couple of weeks, but now I can't remember what to use where. Choose
"Worklist".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266582 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than relying on the structural equivalence of DICompositeType to
merge type definitions, use an explicit map on the LLVMContext that
LLParser and BitcodeReader consult when constructing new nodes.
Each non-forward-declaration DICompositeType with a non-empty
'identifier:' field is stored/loaded from the type map, and the first
definiton will "win".
This map is opt-in: clients that expect ODR types from different modules
to be merged must call LLVMContext::ensureDITypeMap.
- Clients that just happen to load more than one Module in the same
LLVMContext won't magically merge types.
- Clients (like LTO) that want to continue to merge types based on ODR
identifiers should opt-in immediately.
I have updated LTOCodeGenerator.cpp, the two "linking" spots in
gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to
set this.
With this in place, it will be straightforward to remove the DITypeRef
concept (i.e., referencing types by their 'identifier:' string rather
than pointing at them directly).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266549 91177308-0d34-0410-b5e6-96231b3b80d8
To be able to work accurately on the reference graph when taking
decision about internalizing, promoting, renaming, etc. We need
to have the alias information explicit.
Differential Revision: http://reviews.llvm.org/D18836
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266517 91177308-0d34-0410-b5e6-96231b3b80d8
1) We need to add this flag prior to adding any other, in case the user has
specified a -fmodule-cache-path= flag in their custom CXXFLAGS. Such a flag
causes -Werror builds to fail, and thus all config checks fail, until we add
the corresponding -fmodules flag. The modules selfhost bot does this, for
instance.
2) Delete module maps that were putting .cpp files into modules.
3) Enable -fmodules-local-submodule-visibility, to get proper module
visibility rules applied across submodules of the same module. Disable
-fmodules for C builds, since that flag is not available there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266502 91177308-0d34-0410-b5e6-96231b3b80d8
Currently each Function points to a DISubprogram and DISubprogram has a
scope field. For member functions the scope is a DICompositeType. DIScopes
point to the DICompileUnit to facilitate type uniquing.
Distinct DISubprograms (with isDefinition: true) are not part of the type
hierarchy and cannot be uniqued. This change removes the subprograms
list from DICompileUnit and instead adds a pointer to the owning compile
unit to distinct DISubprograms. This would make it easy for ThinLTO to
strip unneeded DISubprograms and their transitively referenced debug info.
Motivation
----------
Materializing DISubprograms is currently the most expensive operation when
doing a ThinLTO build of clang.
We want the DISubprogram to be stored in a separate Bitcode block (or the
same block as the function body) so we can avoid having to expensively
deserialize all DISubprograms together with the global metadata. If a
function has been inlined into another subprogram we need to store a
reference the block containing the inlined subprogram.
Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script
that updates LLVM IR testcases to the new format.
http://reviews.llvm.org/D19034
<rdar://problem/25256815>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266446 91177308-0d34-0410-b5e6-96231b3b80d8
At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.
This is the first part of http://reviews.llvm.org/D19094
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266379 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
To be able to work accurately on the reference graph when taking decision
about internalizing, promoting, renaming, etc. We need to have the alias
information explicit.
Reviewers: tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18836
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266214 91177308-0d34-0410-b5e6-96231b3b80d8
`allocsize` is a function attribute that allows users to request that
LLVM treat arbitrary functions as allocation functions.
This patch makes LLVM accept the `allocsize` attribute, and makes
`@llvm.objectsize` recognize said attribute.
The review for this was split into two patches for ease of reviewing:
D18974 and D14933. As promised on the revisions, I'm landing both
patches as a single commit.
Differential Revision: http://reviews.llvm.org/D14933
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266032 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is the first step in also serializing the index out to LLVM
assembly.
The per-module summary written to bitcode is moved out of the bitcode
writer and to a new analysis pass (ModuleSummaryIndexWrapperPass).
The pass itself uses a new builder class to compute index, and the
builder class is used directly in places where we don't have a pass
manager (e.g. llvm-as).
Because we are computing summaries outside of the bitcode writer, we no
longer can use value ids created by the bitcode writer's
ValueEnumerator. This required changing the reference graph edge type
to use a new ValueInfo class holding a union between a GUID (combined
index) and Value* (permodule index). The Value* are converted to the
appropriate value ID during bitcode writing.
Also, this enables removal of the BitWriter library's dependence on the
Analysis library that was previously required for the summary computation.
Reviewers: joker.eph
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18763
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265941 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.
The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).
This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.
As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.
Reviewers: jyknight, reames
Subscribers: jyknight, llvm-commits
Differential Revision: http://reviews.llvm.org/D18775
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265602 91177308-0d34-0410-b5e6-96231b3b80d8
Add a common parent class for ConstantArray, ConstantVector, and
ConstantStruct called ConstantAggregate. These are the aggregate
subclasses of Constant that take operands.
This is mainly a cleanup, adding common `isa` target and removing
duplicated code. However, it also simplifies caching which constants
point transitively at `GlobalValue` (a possible future direction).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265466 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265370 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Useful for debugging since we lose this correlation after the permodule
summary/VST is read and until we later materialize source modules in the
function importer.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18555
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265327 91177308-0d34-0410-b5e6-96231b3b80d8
The index used to contain only Function, but now contains GlobalValue
in general.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265230 91177308-0d34-0410-b5e6-96231b3b80d8
Whenever metadata is only referenced by a single function, emit the
metadata just in that function block. This should improve lazy-loading
by reducing the amount of metadata in the global block.
For now, this should catch all DILocations, and anything else that
happens to be referenced only by a single function.
It's also a first step toward a couple of possible future directions
(which this commit does *not* implement):
1. Some debug info metadata is only referenced from compile units and
individual functions. If we can drop the link from the compile
unit, this optimization will get more powerful.
2. Any uniqued metadata that isn't referenced globally can in theory be
emitted in every function block that references it (trading off
bitcode size and full-parse time vs. lazy-load time).
Note: this assumes the new BitcodeReader error checking from r265223.
The metadata stored in function blocks gets purged after parsing each
function, which means unresolved forward references will get lost.
Since all the global metadata should have already been resolved by the
time we get to the function metadata blocks we just need to check for
that case. (If for some reason we need to handle bitcode that fails the
checks in r265223, the fix is to store about-to-be-dropped unresolved
nodes in MetadataList::shrinkTo until they can be handled succesfully by
a future call to MetadataList::tryToResolveCycles.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265226 91177308-0d34-0410-b5e6-96231b3b80d8
Further unify the handling of function-local metadata with global
metadata, by exposing the same interface in ValueEnumerator. Both
contexts use the same accessors:
- getMDStrings(): get the strings for this block.
- getNonMDStrings(): get the non-strings for this block.
A future commit will start adding strings to the function-block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265224 91177308-0d34-0410-b5e6-96231b3b80d8
A follow-up commit will start using function metadata blocks more
heavily. This commit adds some error checking to confirm that metadata
is fully resolved before (and after) materializing each function.
This is valid even when reading very old bitcode from before the
metadata/value split. The global metadata block always came before the
function blocks. However, in case somehow this causes a regression
(i.e., an old LLVM did produce such bitcode after all) I'm committing
separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265223 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This should make the code more readable, especially all the map declarations.
Reviewers: tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18721
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265215 91177308-0d34-0410-b5e6-96231b3b80d8
A ``swifterror`` attribute can be applied to a function parameter or an
AllocaInst.
This commit does not include any target-specific change. The target-specific
optimization will come as a follow-up patch.
Differential Revision: http://reviews.llvm.org/D18092
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265189 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265102 91177308-0d34-0410-b5e6-96231b3b80d8
Since we have moved to a model where functions are imported in bulk from
each source module after making summary-based importing decisions, there
is no longer a need to link metadata as a postpass, and all users have
been removed.
This essentially reverts r255909 and follow-on fixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264763 91177308-0d34-0410-b5e6-96231b3b80d8
Support parsing a METADATA_STRINGS record that only has a single piece
of metadata, !"". Fixes a corner case in r264551.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264699 91177308-0d34-0410-b5e6-96231b3b80d8
The caller of ValueEnumerator::EnumerateOperandType never sends in
metadata. Assert that, and remove the unnecessary logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264558 91177308-0d34-0410-b5e6-96231b3b80d8
Change writeFunctionMetadata to call writeMetadataRecords. For now
there's no functionality change, but makes it easy to serialize other
types of metadata in the function block in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264557 91177308-0d34-0410-b5e6-96231b3b80d8
To match writeMetadataRecords, writeNamedMetadata and
writeMetadataStrings, change:
WriteModuleMetadata => writeModuleMetadata
WriteFunctionLocalMetadata => writeFunctionMetadata
Write##CLASS => write##CLASS
The only major change is "FunctionLocal" => "Function". The point is to
be less specific, in preparation for emitting normal metadata records
inside function metadata blocks (currently we only emit
`LocalAsMetadata` there).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264556 91177308-0d34-0410-b5e6-96231b3b80d8
We don't really need a separate vector here; instead, point at a range
inside the main MDs array. This matches how r264551 references the
ranges of strings and non-strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264552 91177308-0d34-0410-b5e6-96231b3b80d8
Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:
vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264551 91177308-0d34-0410-b5e6-96231b3b80d8
The implementation is fairly obvious. This is preparation for using
some blobs in bitcode.
For clarity (and perhaps future-proofing?), I moved the call to
JumpToBit in BitstreamCursor::readRecord ahead of calling
MemoryObject::getPointer, since JumpToBit can theoretically (a) read
bytes, which (b) invalidates the blob pointer.
This isn't strictly necessary the two memory objects we have:
- The return of RawMemoryObject::getPointer is valid until the memory
object is destroyed.
- StreamingMemoryObject::getPointer is valid until the next chunk is
read from the stream. Since the JumpToBit call is only going ahead
to a word boundary, we'll never load another chunk.
However, reordering makes it clear by inspection that the blob returned
by BitstreamCursor::readRecord will be valid.
I added some tests for StreamingMemoryObject::getPointer and
BitstreamCursor::readRecord.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264549 91177308-0d34-0410-b5e6-96231b3b80d8
Add API to SimpleBitstreamCursor to allow users to translate between
byte addresses and pointers.
- jumpToPointer: move the bit position to a particular pointer.
- getPointerToByte: get the pointer for a particular byte.
- getPointerToBit: get the pointer for the byte of the current bit.
- getCurrentByteNo: convenience function for assertions and tests.
Mainly adds unit tests (getPointerToBit/Byte already has a use), but
also preparation for eventually using jumpToPointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264546 91177308-0d34-0410-b5e6-96231b3b80d8
Split out SimpleBitstreamCursor from BitstreamCursor, which is a
lower-level cursor with no knowledge of bitcode blocks, abbreviations,
or records. It just knows how to read bits and navigate the stream.
This is mainly organizational, to separate the API for manipulating raw
bits from that for bitcode concepts like Record and Block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264545 91177308-0d34-0410-b5e6-96231b3b80d8
Optimize output of MDStrings in bitcode. This emits them in big blocks
(currently 1024) in a pair of records:
- BULK_STRING_SIZES: the sizes of the strings in the block, and
- BULK_STRING_DATA: a single blob, which is the concatenation of all
the strings.
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
I needed to add support for blobs to streaming input to get the test
suite passing.
- StreamingMemoryObject::getPointer reads ahead and returns the
address of the blob.
- To avoid a possible reallocation of StreamingMemoryObject::Bytes,
BitstreamCursor::readRecord needs to move the call to JumpToEnd
forward so that getPointer is the last bitstream operation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264409 91177308-0d34-0410-b5e6-96231b3b80d8
Caught by inspection while working on partitioning metadata. It's nice
to produce the same bitcode if you run the compiler twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264381 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation for MODULE_CODE_METADATA_VALUES was to enable an
-flto=thin scheme where:
1. First, one function is cherry-picked from a bitcode file.
2. Later, another function is cherry-picked.
3. Later, ...
4. Finally, the metadata needed by all the previous functions is
loaded.
This was abandoned in favour of:
1. Calculate the superset of functions needed from a Module.
2. Link all functions at once.
Delayed metadata reading no longer serves a purpose. It also adds
a few complication, since we can't count on metadata being properly
parsed when exiting the BitcodeReader. After discussing with Teresa, we
agreed to remove it.
The code that depended on this was removed/updated in r264326.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264378 91177308-0d34-0410-b5e6-96231b3b80d8
Remove logic to upgrade !llvm.loop by changing the MDString tag
directly. This old logic would check (and change) arbitrary strings
that had nothing to do with loop metadata. Instead, check !llvm.loop
attachments directly, and change which strings get attached.
Rather than updating the assembly-based upgrade, drop it entirely. It
has been quite a while since we supported upgrading textual IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264373 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic
for the METADATA_GENERIC_DEBUG abbreviation into WriteGenericDINode.
(This is just like r264302, but for GenericDINode.)
The only change is that the abbreviation is emitted later in the
bitcode, just before the first `GenericDINode` record. This shouldn't
be observable though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264303 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic
for the METADATA_LOCATION abbreviation into WriteDILocation.
The only change is that the abbreviation is emitted later in the
bitcode, just before the first `DILocation` record. This shouldn't be
observable though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264302 91177308-0d34-0410-b5e6-96231b3b80d8
Split writeNamedMetadata out of WriteModuleMetadata to write named
metadata, and createNamedMetadataAbbrev for the abbreviation.
There should be no effective functionality change, although the layout
of the bitcode will change. Previously, the abbreviation was emitted at
the top of the block, but now it is delayed until immediately before the
named metadata records are emitted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264301 91177308-0d34-0410-b5e6-96231b3b80d8
I hit a crash in the bitcode reader on some corrupt input where an
MDString had somehow been attached to an instruction instead of an
MDNode. This input is pretty bogus, but we shouldn't be crashing on bad
input here.
This change adds error handling in all of the places where we
currently have unchecked casts from Metadata to MDNode, which means
we'll error out instead of crashing for that sort of input.
Unfortunately, I don't have tests. Hitting this requires flipping bits
in the input bitcode, and committing corrupt binary files to catch
these cases is a bit too opaque and unmaintainable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263742 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects.
Reviewers: reames, apilipenko, manmanren
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18229
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263673 91177308-0d34-0410-b5e6-96231b3b80d8
Record all variable defs with a summary record to aid in building a
complete reference graph and locating constant variable defs to import.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263576 91177308-0d34-0410-b5e6-96231b3b80d8
Address review suggestions from dblaikie: change a few dyn_cast to cast
and fold a cast into if condition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263526 91177308-0d34-0410-b5e6-96231b3b80d8
Since the static getGlobalIdentifier and getGUID methods are now called
for global values other than functions, reflect that by moving these
methods to the GlobalValue class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263524 91177308-0d34-0410-b5e6-96231b3b80d8
(Resubmitting after fixing missing file issue)
With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.
A companion clang patch will immediately succeed this patch to reflect
this renaming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263513 91177308-0d34-0410-b5e6-96231b3b80d8
With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.
A companion clang patch will immediately succeed this patch to reflect
this renaming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263490 91177308-0d34-0410-b5e6-96231b3b80d8
It had a weird artificial limitation on the write side: the comdat name
couldn't be bigger than 2**16. However, the reader had no such
limitation. Make the reader and the writer agree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263377 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds support for including a full reference graph including
call graph edges and other GV references in the summary.
The reference graph edges can be used to make importing decisions
without materializing any source modules, can be used in the plugin
to make file staging decisions for distributed build systems, and is
expected to have other uses.
The call graph edges are recorded in each function summary in the
bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO
data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when
there is PGO, where the ValueId can be mapped to the function GUID via
the ValueSymbolTable. In the function index in memory, the call graph
edges reference the target via the CalleeGUID instead of the
CalleeValueId.
The reference graph edges are recorded in each summary record with a
list of referenced value IDs, which can be mapped to value GUID via the
ValueSymbolTable.
Addtionally, a new summary record type is added to record references
from global variable initializers. A number of bitcode records and data
structures have been renamed to reflect the newly expanded scope of the
summary beyond functions. More cleanup will follow.
Reviewers: joker.eph, davidxl
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D17212
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263275 91177308-0d34-0410-b5e6-96231b3b80d8
This wasn't causing a correctness issue, but was causing extra duplicate
entries to be added to the SummaryMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261757 91177308-0d34-0410-b5e6-96231b3b80d8
When emitting the source filename, the encoding of the string
was checked against the name instead of the filename.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261019 91177308-0d34-0410-b5e6-96231b3b80d8
This restores commit r260408, along with a fix for a bot failure.
The bot failure was caused by dereferencing a unique_ptr in the same
call instruction parameter list where it was passed via std::move.
Apparently due to luck this was not exposed when I built the compiler
with clang, only with gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260442 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch uses the lower 64-bits of the MD5 hash of a function name as
a GUID in the function index, instead of storing function names. Any
local functions are first given a global name by prepending the original
source file name. This is the same naming scheme and GUID used by PGO in
the indexed profile format.
This change has a couple of benefits. The primary benefit is size
reduction in the combined index file, for example 483.xalancbmk's
combined index file was reduced by around 70%. It should also result in
memory savings for the index file in memory, as the in-memory map is
also indexed by the hash instead of the string.
Second, this enables integration with indirect call promotion, since the
indirect call profile targets are recorded using the same global naming
convention and hash. This will enable the function importer to easily
locate function summaries for indirect call profile targets to enable
their import and subsequent promotion.
The original source file name is recorded in the bitcode in a new
module-level record for use in the ThinLTO backend pipeline.
Reviewers: davidxl, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17028
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260408 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Adds the linkage type to both the per-module and combined function
summaries, which subsumes the current islocal bit. This will eventually
be used to optimized linkage types based on global summary-based
analysis.
Reviewers: joker.eph
Subscribers: joker.eph, davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D16943
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259993 91177308-0d34-0410-b5e6-96231b3b80d8
Iterate over the function list instead of a DenseMap of Function pointers
when emitting the function summary into the module.
This fixes PR26419.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259398 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables llvm-bcanalyzer to print the bitcode wrapper header
if the file has one, which is needed to test the changes made in
r258627 (bitcode-wrapper-header-armv7m.ll is the test case for r258627).
Differential Revision: http://reviews.llvm.org/D16642
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259162 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258861 91177308-0d34-0410-b5e6-96231b3b80d8
target is macho.
It looks like the check for macho was accidentally dropped in r132959.
I don't have a test case, but I'll add one if anyone knows how this can
be tested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258627 91177308-0d34-0410-b5e6-96231b3b80d8
Replace sequences of count() followed by operator[] with either
find() or insert(), depending on the context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258405 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r257751, bringing back r256105.
The problem the assert found was fixed in r257915.
Original commit message:
Assert that we have all use/users in the getters.
An error that is pretty easy to make is to use the lazy bitcode reader
and then do something like
if (V.use_empty())
The problem is that uses in unmaterialized functions are not accounted
for.
This patch adds asserts that all uses are known.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257920 91177308-0d34-0410-b5e6-96231b3b80d8
In r254991 I allowed ConstantDataVectors to contain elements of
HalfTy, but I missed updating the bitcode reader and writer to handle
this, so now we crash if we try to emit bitcode on programs that have
constant vectors of half.
This fixes the issue and adds test coverage for reading and writing
constant sequences in bitcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256982 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested in review for r255909, add a way to ensure that temporary
MD used as keys in the MetadataToID map during ThinLTO importing are not
RAUWed.
Add support for marking an MDNode as not replaceable. Clear the new
CanReplace flag when adding a temporary MD node to the MetadataToID map
and clear it when destroying the map.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256648 91177308-0d34-0410-b5e6-96231b3b80d8
Add an assert suggested in review for r255909 to ensure that MDNodes
saved in the map used for metadata linking are either temporary or
resolved.
Also add a comment clarifying why we may need to save off non-MDNode
metadata.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256646 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bug introduced by the ThinLTO metadata linking patch
r255909. The assert is overly-strict and while useful in development of
the patch, doesn't seem interesting to keep.
Fixes PR25907.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256161 91177308-0d34-0410-b5e6-96231b3b80d8
An error that is pretty easy to make is to use the lazy bitcode reader
and then do something like
if (V.use_empty())
The problem is that uses in unmaterialized functions are not accounted
for.
This patch adds asserts that all uses are known.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256105 91177308-0d34-0410-b5e6-96231b3b80d8
Make personality functions, prefix data, and prologue data hungoff
operands of Function.
This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Includes a fix to scrub value subclass data in dropAllReferences. Does not
use binary literals.
Differential Revision: http://reviews.llvm.org/D13829
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256095 91177308-0d34-0410-b5e6-96231b3b80d8
Make personality functions, prefix data, and prologue data hungoff
operands of Function.
This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Includes a fix to scrub value subclass data in dropAllReferences.
Differential Revision: http://reviews.llvm.org/D13829
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256093 91177308-0d34-0410-b5e6-96231b3b80d8
Make personality functions, prefix data, and prologue data hungoff
operands of Function.
This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Differential Revision: http://reviews.llvm.org/D13829
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256090 91177308-0d34-0410-b5e6-96231b3b80d8
This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule
They are replaced with the functions with a 2 suffix which do not record
a diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256065 91177308-0d34-0410-b5e6-96231b3b80d8
This inlines materializeAll into the only caller
(materializeAllPermanently) and renames materializeAllPermanently to
just materializeAll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256024 91177308-0d34-0410-b5e6-96231b3b80d8
It was only used on lib/Linker and the use was "dead" since it was used on a
function the IRMover had just moved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256019 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255965 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255909 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch introduces two new function attributes
InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone.
inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly
Test cases have been updated. This revision uses this (d001932f3a) as reference.
Reviewers: jmolloy, hfinkel
Subscribers: reames, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D15499
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255778 91177308-0d34-0410-b5e6-96231b3b80d8
This patch converts code that has access to a LLVMContext to not take a
diagnostic handler.
This has a few advantages
* It is easier to use a consistent diagnostic handler in a single program.
* Less clutter since we are not passing a handler around.
It does make it a bit awkward to implement some C APIs that return a
diagnostic string. I will propose new versions of these APIs and
deprecate the current ones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255571 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds optional fast-math-flags (the same that apply to fmul/fadd/fsub/fdiv/frem/fcmp)
to call instructions in IR. Follow-up patches would use these flags in LibCallSimplifier, add
support to clang, and extend FMF to the DAG for calls.
Motivating example:
%y = fmul fast float %x, %x
%z = tail call float @sqrtf(float %y)
We'd like to be able to optimize sqrt(x*x) into fabs(x). We do this today using a function-wide
attribute for unsafe-math, but we really want to trigger on the instructions themselves:
%z = tail call fast float @sqrtf(float %y)
because in an LTO build it's possible that calls with fast semantics have been inlined into a
function with non-fast semantics.
The code changes and tests are based on the recent commits that added "notail":
http://reviews.llvm.org/rL252368
and added FMF to fcmp:
http://reviews.llvm.org/rL241901
Differential Revision: http://reviews.llvm.org/D14707
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255555 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that terminatepad gives little benefit over a cleanuppad
which calls the termination function. This is not sufficient to
implement fully generic filters but MSVC doesn't support them which
makes terminatepad a little over-designed.
Depends on D15478.
Differential Revision: http://reviews.llvm.org/D15479
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255522 91177308-0d34-0410-b5e6-96231b3b80d8
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255422 91177308-0d34-0410-b5e6-96231b3b80d8
There is no real reason the index has to have the concept of an
exporting Module. We should be able to have one single unique
instance of the Index, and it should be read-only after creation
for the whole ThinLTO processing.
The linker plugin should be able to process multiple modules (in
parallel or in sequence) with the same index.
The only reason the ExportingModule was present seems to be to
implement hasExportedFunctions() that is used by the Module linker
to decide what to do with the current Module.
For now I replaced it with a query to the map of Modules path to
see if this module was declared in the Index and consider that if
it is the case then it is probably exporting function.
On the long term the Linker interface needs to evolve and this
call should not be needed anymore.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254581 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Several fixes to the handling of bitcode files without function summary
sections so that they are skipped during ThinLTO processing in llvm-lto
and the gold plugin when appropriate instead of aborting.
1 Don't assert when trying to add a FunctionInfo that doesn't have
a summary attached.
2 Skip FunctionInfo structures that don't have attached function summary
sections when trying to create the combined function summary.
3 In both llvm-lto and gold-plugin, check whether a bitcode file has
a function summary section before trying to parse the index, and skip
the bitcode file if it does not.
4 Fix hasFunctionSummaryInMemBuffer in BitcodeReader, which had a bug
where we returned to early while looking for the summary section.
Also added llvm-lto and gold-plugin based tests for cases where we
don't have function summaries in the bitcode file. I verified that
either the first couple fixes described above are enough to avoid the
crashes, or fixes 1,3,4. But have combined them all here for added
robustness.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D14903
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253796 91177308-0d34-0410-b5e6-96231b3b80d8
This assert was meant to execute at the end of parseMetadata, but
we return early and never reach the end of the function. Caught
by a compile-time warning since the function doesn't return a value
from that location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253762 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is split out from the ThinLTO metadata mapping patch
http://reviews.llvm.org/D14752.
To avoid needing to parse the module level metadata during function
importing, a new module-level record is added which holds the
number of module-level metadata values. This is required because
metadata value ids are assigned implicitly during parsing, and the
function-level metadata ids start after the module-level metadata ids.
I made a change to this version of the code compared to D14752
in order to add more consistent and thorough assertion checking of the
new record value. We now unconditionally use the record value to
initialize the MDValueList size, and handle it the same in parseMetadata
for all module level metadata cases (lazy loading or not).
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D14825
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253668 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are currently two blocks with the METADATA_BLOCK id at module
scope. The first has the module-level metadata values (consisting of
some combination of METADATA_* record codes except for METADATA_KIND).
The second consists only of METADATA_KIND records. The latter is used
only in the METADATA_ATTACHMENT block within function blocks (for
metadata attached to instructions).
For ThinLTO we want to delay the parsing of module level metadata
until all functions have been imported from that module (there is some
bookkeeping used to suture it up when we read it during a post-pass).
However, we do need the METADATA_KIND records when parsing the function
body during importing, since those kinds are used as described above.
To simplify identification and parsing of just the block containing
the metadata kinds, use a different block id (METADATA_KIND_BLOCK_ID).
Support older bitcode without the new block id as well.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D14654
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253154 91177308-0d34-0410-b5e6-96231b3b80d8
No code uses this functionality yet. This change just exposes
information / structure that was already present.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252644 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Mimic parseTriple(); and exposes it to LTOModule.cpp
Reviewers: dexonsmith, rafael
Subscribers: llvm-commits
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252442 91177308-0d34-0410-b5e6-96231b3b80d8
This marker prevents optimization passes from adding 'tail' or
'musttail' markers to a call. Is is used to prevent tail call
optimization from being performed on the call.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12923
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252368 91177308-0d34-0410-b5e6-96231b3b80d8
This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252282 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, subprograms contained a metadata reference to the function they
described. Because most clients need to get or set a subprogram for a given
function rather than the other way around, this created unneeded inefficiency.
For example, many passes needed to call the function llvm::makeSubprogramMap()
to build a mapping from functions to subprograms, and the IR linker needed to
fix up function references in a way that caused quadratic complexity in the IR
linking phase of LTO.
This change reverses the direction of the edge by storing the subprogram as
function-level metadata and removing DISubprogram's function field.
Since this is an IR change, a bitcode upgrade has been provided.
Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is
attached to the PR.
Differential Revision: http://reviews.llvm.org/D14265
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252219 91177308-0d34-0410-b5e6-96231b3b80d8
This Abbrev was not emitted and basically unused, just leacking there.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252110 91177308-0d34-0410-b5e6-96231b3b80d8
This assert was reachable from user input. A minimized test case (no
FUNCTION_BLOCK_ID record) is attached.
Bug found with afl-fuzz
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251910 91177308-0d34-0410-b5e6-96231b3b80d8
No test, since it would depend on what the compiler can optimize/reuse.
My next commit made this bug visible on Linux Release compiles with some
versions of gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251909 91177308-0d34-0410-b5e6-96231b3b80d8
This restores commit r251837, with the new library dependence added to
llvm-link/Makefile to address bot failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251866 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r251837, due to a number of bot failures of the form:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function
loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined
reference to
'llvm::object::FunctionIndexObjectFile::create(llvm::MemoryBufferRef,
llvm::LLVMContext&, llvm::Module const*, bool)'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function
loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined
reference to 'llvm::object::FunctionIndexObjectFile::takeIndex()'
I'm not sure why these are happening - I added Object to the requred
libraries in tools/llvm-link/LLVMBuild.txt and the LLVM_LINK_COMPONENTS
in tools/llvm-link/CMakeLists.txt. Confirmed for my build that these
symbols come out of libLLVMObject.a. What am I missing?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251841 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Support for necessary linkage changes and symbol renaming during
ThinLTO function importing.
Also includes llvm-link support for manually importing functions
and associated llvm-link based tests.
Note that this does not include support for intelligently importing
metadata, which is currently imported duplicate times. That support will
be in the follow-on patch, and currently is ignored by the tests.
Reviewers: dexonsmith, joker.eph, davidxl
Subscribers: tobiasvk, tejohnson, llvm-commits
Differential Revision: http://reviews.llvm.org/D13515
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251837 91177308-0d34-0410-b5e6-96231b3b80d8
This assert was reachable from user input. A minimized test case (no
FUNCTION_BLOCK_ID record) is attached.
Bug found with afl-fuzz
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251667 91177308-0d34-0410-b5e6-96231b3b80d8
Use 10 bits to represent calling convention ID's instead of 13, and
update the bitcode compatibility tests accordingly. We now error-out in
the bitcode reader when we see bad calling conv ID's.
Thanks to rnk and dexonsmith for feedback!
Differential Revision: http://reviews.llvm.org/D13826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251452 91177308-0d34-0410-b5e6-96231b3b80d8
Processing bitcode from a different LLVM version can lead to
unexpected behavior. The LLVM project guarantees autoupdating
bitcode from a previous minor revision for the same major, but
can't make any promise when reading bitcode generated from a
either a non-released LLVM, a vendor toolchain, or a "future"
LLVM release. This patch aims at being more user-friendly and
allows a bitcode produce to emit an optional block at the
beginning of the bitcode that will contains an opaque string
intended to describe the bitcode producer information. The
bitcode reader will dump this information alongside any error it
reports.
The optional block also includes an "epoch" number, monotonically
increasing when incompatible changes are made to the bitcode. The
reader will reject bitcode whose epoch is different from the one
expected.
Differential Revision: http://reviews.llvm.org/D13666
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251325 91177308-0d34-0410-b5e6-96231b3b80d8
Now LLVMBitWriter compiles without implicit ilist iterator conversions.
In these cases, the cleanest thing was to switch to range-based for
loops. Since there wasn't much noise I converted sub-loops and parent
loops as a drive-by.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250144 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The change to use the VST function entries for lazy deserialization did
not handle the case of anonymous functions without aliases. In that case
we must fall back to scanning the function blocks as there is no VST
entry.
Reviewers: dexonsmith, joker.eph, davidxl
Subscribers: tstellarAMD, llvm-commits
Differential Revision: http://reviews.llvm.org/D13596
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249947 91177308-0d34-0410-b5e6-96231b3b80d8
Removed an unused abbrev op in the VST_CODE_COMBINED_FNENTRY abbrev.
I noticed while writing/testing an array string dumper for
llvm-bcanalyze that the combined function's VST entry abbrevs contained
an old field that I am not using. Everything was working fine since the
bitcode writer and reader were in sync on how the record fields were
actually being set up and interpreted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249691 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The bitcode format is described in this document:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
For more info on ThinLTO see:
https://sites.google.com/site/llvmthinlto
The first customer is ThinLTO, however the data structures are designed
and named more generally based on prior feedback. There are a few
comments regarding how certain interfaces are used by ThinLTO, and the
options added here to gold currently have ThinLTO-specific names as the
behavior they provoke is currently ThinLTO-specific.
This patch includes support for generating per-module function indexes,
the combined index file via the gold plugin, and several tests
(more are included with the associated clang patch D11908).
Reviewers: dexonsmith, davidxl, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13107
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249270 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This also adds the first set of tests for operand bundles.
The optimizer has not been audited to ensure that it does the right
thing with operand bundles.
Depends on D12456.
Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner
Subscribers: maksfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D12457
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248551 91177308-0d34-0410-b5e6-96231b3b80d8
Since aliases actually use and verify their explicit type already, no
further invalid testing is required here. The
invalid.test:ALIAS-TYPE-MISMATCH case catches errors due to emitting a
non-pointee type in the new format or a non-pointer type in the old
format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247952 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r247898 (which reverted r247894).
Patch fixed to address two issues exposed by buildbots:
- unused variable warning in NDEBUG mode
- std::initializer_list lifetime issue causing test failures
Original Summary:
Support for including the function bitcode indices in the Value Symbol
Table. This requires writing the VST after the function blocks, which in
turn requires a new VST forward declaration record encoding the offset of
the full VST (which is backpatched to contain the offset after the VST
is written).
This patch also enables the lazy function reader to use the new function
indices out of the VST. This support will be used by ThinLTO as well, which
will be in a follow on patch. Backwards compatibility with older bitcode
files is maintained.
A new test is also included.
The bitcode format (used for the lazy reader as well as the upcoming
ThinLTO patches) came out of discussions with Duncan and others and is
described here:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
Reviewers: dexonsmith, davidxl, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247927 91177308-0d34-0410-b5e6-96231b3b80d8
Temporarily revert to fix some buildbot issues. One is a minor issue
with a variable unused in NDEBUG mode. More concerning are some test
failures on win7 that I need to dig into.
This reverts commit 4e66a74543459832cfd571db42b4543580ae1d1d.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247898 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Support for including the function bitcode indices in the Value Symbol
Table. This requires writing the VST after the function blocks, which in
turn requires a new VST forward declaration record encoding the offset of
the full VST (which is backpatched to contain the offset after the VST
is written).
This patch also enables the lazy function reader to use the new function
indices out of the VST. This support will be used by ThinLTO as well, which
will be in a follow on patch. Backwards compatibility with older bitcode
files is maintained.
A new test is also included.
The bitcode format (used for the lazy reader as well as the upcoming
ThinLTO patches) came out of discussions with Duncan and others and is
described here:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
Reviewers: dexonsmith, davidxl, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247894 91177308-0d34-0410-b5e6-96231b3b80d8
This was a flawed change - it just caused the getElementType call to be
deferred until later, when we really need to remove it. Now that the IR
for GlobalAliases has been updated, the root cause is addressed that way
instead and this change is no longer needed (and in fact gets in the way
- because we want to pass the pointee type directly down further).
Follow up patches to push this through GlobalValue, bitcode format, etc,
will come along soon.
This reverts commit 236160.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247585 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a `cleanupendpad` instruction, used to mark exceptional exits out of
cleanups (for languages/targets that can abort a cleanup with another
exception). The `cleanupendpad` instruction is similar to the `catchendpad`
instruction in that it is an EH pad which is the target of unwind edges in
the handler and which itself has an unwind edge to the next EH action.
The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad`
argument indicating which cleanup it exits. The unwind successors of a
`cleanuppad`'s `cleanupendpad`s must agree with each other and with its
`cleanupret`s.
Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12433
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246751 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Constant vectors weren't allowed to have an i1 condition in the
BitcodeReader. Make sure we have the same restrictions that are
documented, not more.
Reviewers: nlewycky, rafael, kschimpf
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12440
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246459 91177308-0d34-0410-b5e6-96231b3b80d8
As a follow-up to r246098, require `DISubprogram` definitions
(`isDefinition: true`) to be 'distinct'. Specifically, add an assembler
check, a verifier check, and bitcode upgrading logic to combat testcase
bitrot after the `DIBuilder` change.
While working on the testcases, I realized that
test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its
purpose was to check for a corner case in PR22792 where two subprogram
definitions match exactly and share the same metadata node. The new
verifier check, requiring that subprogram definitions are 'distinct',
precludes that possibility.
I updated almost all the IR with the following script:
git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' |
grep -v test/Bitcode |
xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/'
Likely some variant of would work for out-of-tree testcases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246327 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
WinEHPrepare is going to require that cleanuppad and catchpad produce values
of token type which are consumed by any cleanupret or catchret exiting the
pad. This change updates the signatures of those operators to require/enforce
that the type produced by the pads is token type and that the rets have an
appropriate argument.
The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and
similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that
restriction, this change adds a notion of an operator constraint to both
LLParser and BitcodeReader, allowing appropriate sentinels to be constructed
for forward references and appropriate error messages to be emitted for
illegal inputs.
Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad
predecessor must have no other predecessors; this ensures that WinEHPrepare
will see the expected linear relationship between sibling catches on the
same try.
Lastly, remove some superfluous/vestigial casts from instruction operand
setters operating on BasicBlocks.
Reviewers: rnk, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12108
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245797 91177308-0d34-0410-b5e6-96231b3b80d8
Some personality routines require funclet exit points to be clearly
marked, this is done by producing a token at the funclet pad and
consuming it at the corresponding ret instruction. CleanupReturnInst
already had a spot for this operand but CatchReturnInst did not.
Other personality routines don't need to use this which is why it has
been made optional.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245149 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces the basic functionality to support "token types".
The motivation stems from the need to perform operations on a Value
whose provenance cannot be obscured.
There are several applications for such a type but my immediate
motivation stems from WinEH. Our personality routine enforces a
single-entry - single-exit regime for cleanups. After several rounds of
optimizations, we may be left with a terminator whose "cleanup-entry
block" is not entirely clear because control flow has merged two
cleanups together. We have experimented with using labels as operands
inside of instructions which are not terminators to indicate where we
came from but found that LLVM does not expect such exotic uses of
BasicBlocks.
Instead, we can use this new type to clearly associate the "entry point"
and "exit point" of our cleanup. This is done by having the cleanuppad
yield a Token and consuming it at the cleanupret.
The token type makes it impossible to obscure or otherwise hide the
Value, making it trivial to track the relationship between the two
points.
What is the burden to the optimizer? Well, it turns out we have already
paid down this cost by accepting that there are certain calls that we
are not permitted to duplicate, optimizations have to watch out for
such instructions anyway. There are additional places in the optimizer
that we will probably have to update but early examination has given me
the impression that this will not be heroic.
Differential Revision: http://reviews.llvm.org/D11861
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245029 91177308-0d34-0410-b5e6-96231b3b80d8
Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s.
The backend is liable to start relying on that (if it hasn't already),
so make uniquable `DICompileUnit`s illegal and automatically upgrade old
bitcode. This is a nice cleanup, since we can remove an unnecessary
`DenseSet` (and the associated uniquing info) from `LLVMContextImpl`.
Almost all the testcases were updated with this script:
git grep -e '= !DICompileUnit' -l -- test |
grep -v test/Bitcode |
xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,'
I imagine something similar should work for out-of-tree testcases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243885 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags,
using `DW_TAG_variable` in their place Stop exposing the `tag:` field at
all in the assembly format for `DILocalVariable`.
Most of the testcase updates were generated by the following sed script:
find test/ -name "*.ll" -o -name "*.mir" |
xargs grep -l 'DILocalVariable' |
xargs sed -i '' \
-e 's/tag: DW_TAG_arg_variable, //' \
-e 's/tag: DW_TAG_auto_variable, //'
There were only a handful of tests in `test/Assembly` that I needed to
update by hand.
(Note: a follow-up could change `DILocalVariable::DILocalVariable()` to
set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable`
(as appropriate), instead of having that logic magically in the backend
in `DbgVariable`. I've added a FIXME to that effect.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243774 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces new instructions neccessary to implement MSVC-compatible
exception handling support. Most of the middle-end and none of the
back-end haven't been audited or updated to take them into account.
Differential Revision: http://reviews.llvm.org/D11097
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243766 91177308-0d34-0410-b5e6-96231b3b80d8
Swift has a custom calling convention that also requires some new flags
on arguments and one new attribute on alloca instructions. This patch
does not include the implementation of that calling convention - that
will be provided as part of the open-source release of Swift; this only
reserves the bitcode constant values so that they are not used for
other purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243379 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis.
Differential Revision: http://reviews.llvm.org/D10398
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241979 91177308-0d34-0410-b5e6-96231b3b80d8
FCmp behaves a lot like a floating-point binary operator in many ways,
and can benefit from fast-math information. Flags such as nsz and nnan
can affect if this fcmp (in combination with a select) can be treated
as a fminnum/fmaxnum operation.
This adds backwards-compatible bitcode support, IR parsing and writing,
LangRef changes and IRBuilder changes. I'll need to audit InstSimplify
and InstCombine in a followup to find places where flags should be
copied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241901 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This introduces new instructions neccessary to implement MSVC-compatible
exception handling support. Most of the middle-end and none of the
back-end haven't been audited or updated to take them into account.
Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11041
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241888 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Looking at r241279, I noticed that UpgradedIntrinsics only gets written
to in the following code:
if (UpgradeIntrinsicFunction(&F, NewFn))
UpgradedIntrinsics[&F] = NewFn;
Looking through UpgradeIntrinsicFunction, we always return false OR
NewFn will be set to a different function from our source.
This patch pulls the F != NewFn into UpgradeIntrinsicFunction as an
assert, and removes the check from callers of UpgradeIntrinsicFunction.
Reviewers: rafael, chandlerc
Subscribers: llvm-commits-list
Differential Revision: http://reviews.llvm.org/D10915
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241369 91177308-0d34-0410-b5e6-96231b3b80d8
When trying to upgrade @llvm.x86.sse2.psrl.dq while parsing a module,
BitcodeReader adds the function to its worklist twice, resulting in a
crash when accessing it the second time.
This patch replaces the worklist vector by a map.
Patch by Philip Pfaffe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241281 91177308-0d34-0410-b5e6-96231b3b80d8
It is meant to be used to record modules @imported by the current
compile unit, so a debugger an import the same modules to replicate this
environment before dropping into the expression evaluator.
DIModule is a sibling to DINamespace and behaves quite similarly.
In addition to the name of the module it also records the module
configuration details that are necessary to uniquely identify the module.
This includes the configuration macros (e.g., -DNDEBUG), the include path
where the module.map file is to be found, and the isysroot.
The idea is that the backend will turn this into a DW_TAG_module.
http://reviews.llvm.org/D9614
rdar://problem/20965932
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241017 91177308-0d34-0410-b5e6-96231b3b80d8
A number of places had explicit loops over Constant::operands().
Just use foreach loops where possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240694 91177308-0d34-0410-b5e6-96231b3b80d8
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
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240137 91177308-0d34-0410-b5e6-96231b3b80d8
The personality routine currently lives in the LandingPadInst.
This isn't desirable because:
- All LandingPadInsts in the same function must have the same
personality routine. This means that each LandingPadInst beyond the
first has an operand which produces no additional information.
- There is ongoing work to introduce EH IR constructs other than
LandingPadInst. Moving the personality routine off of any one
particular Instruction and onto the parent function seems a lot better
than have N different places a personality function can sneak onto an
exceptional function.
Differential Revision: http://reviews.llvm.org/D10429
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239940 91177308-0d34-0410-b5e6-96231b3b80d8
Without this the included unit test would assert in
assert(BasicBlockFwdRefs.empty() && "Unresolved blockaddress fwd references");
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239871 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch the bitcode reader would read a module from a file
that contained in order:
* Any number of non MODULE_BLOCK sub blocks.
* One MODULE_BLOCK
* Any number of non MODULE_BLOCK sub blocks.
* 4 '\n' characters to handle OS X's ranlib.
Since we support lazy reading of modules, any information that is relevant
for the module has to be in the MODULE_BLOCK or before it. We don't gain
anything from checking what is after.
This patch then changes the reader to stop once the MODULE_BLOCK has been
successfully parsed.
This avoids the ugly special case for .bc files in an archive and makes it
easier to embed bitcode files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239845 91177308-0d34-0410-b5e6-96231b3b80d8
`LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td`
needs to regenerate `Instrinsics.h` before anyone can include anything
from the LLVM_IR module. Represent the dependency explicitly to prevent
that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239796 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).
The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.
Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.
This patch is our implementation of the safe stack on top of LLVM. The
patches make the following changes:
- Add the safestack function attribute, similar to the ssp, sspstrong and
sspreq attributes.
- Add the SafeStack instrumentation pass that applies the safe stack to all
functions that have the safestack attribute. This pass moves all unsafe local
variables to the unsafe stack with a separate stack pointer, whereas all
safe variables remain on the regular stack that is managed by LLVM as usual.
- Invoke the pass as the last stage before code generation (at the same time
the existing cookie-based stack protector pass is invoked).
- Add unit tests for the safe stack.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6094
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239761 91177308-0d34-0410-b5e6-96231b3b80d8
Use the same argument names as the members.
Use default member initializes.
Extracted from a patch by Karl Schimpf.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239749 91177308-0d34-0410-b5e6-96231b3b80d8
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238602 91177308-0d34-0410-b5e6-96231b3b80d8
so DWARF skeleton CUs can be expression in IR. A skeleton CU is a
(typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and
a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info.
This is a prerequisite for clang module debugging as discussed in
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html.
In order to refer to external types stored in split DWARF (dwo) objects,
such as clang modules, we need to emit skeleton CUs, which identify the
dwarf object (i.e., the clang module) by filename (the SplitDebugFilename)
and a hash value, the dwo_id.
This patch only contains the IR changes. The idea is that a CUs with a
non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name
and DW_AT_GNU_dwo_id attribute.
http://reviews.llvm.org/D9488
rdar://problem/20091852
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237949 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Added isLoadableOrStorableType to PointerType.
We were doing some checks in some places, occasionally assert()ing instead
of telling the caller. With this patch, I'm putting all type checking in
the same place for load/store type instructions, and verifying the same
thing every time.
I also added a check for load/store of a function type.
Applied extracted check to Load, Store, and Cmpxcg.
I don't have exhaustive tests for all of these, but all Error() calls in
TypeCheckLoadStoreInst are being tested (in invalid.test).
Reviewers: dblaikie, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9785
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237619 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN`
records since. Add it back. Also tests that the output assembly looks
okay.
Fixes PR23436.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236661 91177308-0d34-0410-b5e6-96231b3b80d8
Many of the callers already have the pointer type anyway, and for the
couple of callers that don't it's pretty easy to call PointerType::get
on the pointee type and address space.
This avoids LLParser from using PointerType::getElementType when parsing
GlobalAliases from IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236160 91177308-0d34-0410-b5e6-96231b3b80d8
Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`. The last of the `DIDescriptor` classes were deleted in
r235356, and the last of the related typedefs removed in r235413, so
this has all baked for about a week.
Note: If you have out-of-tree code (like a frontend), I recommend that
you get everything compiling and tests passing with the *previous*
commit before updating to this one. It'll be easier to keep track of
what code is using the `DIDescriptor` hierarchy and what you've already
updated, and I think you're extremely unlikely to insert bugs. YMMV of
course.
Back to *this* commit: I did this using the rename-md-di-nodes.sh
upgrade script I've attached to PR23080 (both code and testcases) and
filtered through clang-format-diff.py. I edited the tests for
test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns
were off-by-three. It should work on your out-of-tree testcases (and
code, if you've followed the advice in the previous paragraph).
Some of the tests are in badly named files now (e.g.,
test/Assembler/invalid-mdcompositetype-missing-tag.ll should be
'dicompositetype'); I'll come back and move the files in a follow-up
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236120 91177308-0d34-0410-b5e6-96231b3b80d8
