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
