Commit Graph

1053 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith 5ab2be094e IR: Use an explicit map for debug info type uniquing
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).

llvm-svn: 266549
2016-04-17 03:58:21 +00:00
Mehdi Amini 2d28f7aa07 ThinLTO: Make aliases explicit in the 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.

Differential Revision: http://reviews.llvm.org/D18836

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266517
2016-04-16 06:56:44 +00:00
Adrian Prantl 75819aedf6 [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.
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>

llvm-svn: 266446
2016-04-15 15:57:41 +00:00
Mehdi Amini 03b42e41bf Remove every uses of getGlobalContext() in LLVM (but the C API)
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>
llvm-svn: 266379
2016-04-14 21:59:01 +00:00
Mehdi Amini b5b289339b Revert "Make aliases explicit in the summary"
Inadvertently commited...

This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266215
2016-04-13 17:20:07 +00:00
Mehdi Amini ce744a95fd Make aliases explicit in the summary
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>
llvm-svn: 266214
2016-04-13 17:18:42 +00:00
George Burgess IV 278199f615 Add the allocsize attribute to LLVM.
`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

llvm-svn: 266032
2016-04-12 01:05:35 +00:00
Dmitry Polukhin a1feff7024 [GCC] Attribute ifunc support in llvm
This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function alias with type @gnu_indirect_function. Patch
for Clang http://reviews.llvm.org/D15524

Differential Revision: http://reviews.llvm.org/D15525

llvm-svn: 265667
2016-04-07 12:32:19 +00:00
JF Bastien 800f87a871 NFC: make AtomicOrdering an enum class
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

llvm-svn: 265602
2016-04-06 21:19:33 +00:00
Dmitry Polukhin a3d5b0b218 [IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similar
Second part extracted from http://reviews.llvm.org/D15525

Use GlobalIndirectSymbol in all cases when aliases and ifuncs have
something in common.

Differential Revision: http://reviews.llvm.org/D18754

llvm-svn: 265382
2016-04-05 08:47:51 +00:00
Teresa Johnson fb7c764496 [ThinLTO] Refactor some common code into getGlobalValueInfo method (NFC)
Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.

llvm-svn: 265370
2016-04-05 00:40:16 +00:00
Teresa Johnson 916495d894 [ThinLTO] Add option to dump value name to GUID mapping
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

llvm-svn: 265327
2016-04-04 18:52:58 +00:00
Duncan P. N. Exon Smith 8742de9b20 BitcodeReader: Check for unresolved function metadata
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.

llvm-svn: 265223
2016-04-02 14:55:01 +00:00
Mehdi Amini ad5741b075 Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC)
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>
llvm-svn: 265215
2016-04-02 05:07:53 +00:00
Manman Ren 9bfd0d03e9 Swift Calling Convention: add swifterror attribute.
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

llvm-svn: 265189
2016-04-01 21:41:15 +00:00
Mehdi Amini d7ad221c16 Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"
This is intended to be used for ThinLTO incremental build.

Differential Revision: http://reviews.llvm.org/D18213

This is a recommit of r265095 after fixing the Windows issues.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265111
2016-04-01 05:33:11 +00:00
Mehdi Amini 85fb9e058e Revert "Add support for computing SHA1 in LLVM"
This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265102
2016-04-01 03:03:21 +00:00
Mehdi Amini 4c2ed3337d Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"
This is intended to be used for ThinLTO incremental build.

Differential Revision: http://reviews.llvm.org/D18213

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265095
2016-04-01 01:30:06 +00:00
Duncan P. N. Exon Smith 7457ecbebe BitcodeReader: Fix weird whitespace, NFC
llvm-svn: 264822
2016-03-30 04:21:52 +00:00
Teresa Johnson b703c77b03 [ThinLTO] Remove post-pass metadata linking support
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.

llvm-svn: 264763
2016-03-29 18:24:19 +00:00
Manman Ren f46262e0b7 Swift Calling Convention: add swiftself attribute.
Differential Revision: http://reviews.llvm.org/D17866

llvm-svn: 264754
2016-03-29 17:37:21 +00:00
Duncan P. N. Exon Smith bb7ce3b850 BitcodeReader: Allow METADATA_STRINGS to only have !""
Support parsing a METADATA_STRINGS record that only has a single piece
of metadata, !"".  Fixes a corner case in r264551.

llvm-svn: 264699
2016-03-29 05:25:17 +00:00
Duncan P. N. Exon Smith 6565a0d4b2 Reapply ~"Bitcode: Collect all MDString records into a single blob"
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.

llvm-svn: 264551
2016-03-27 23:17:54 +00:00
Duncan P. N. Exon Smith 456c9968e5 Support: Implement StreamingMemoryObject::getPointer
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.

llvm-svn: 264549
2016-03-27 23:00:59 +00:00
Duncan P. N. Exon Smith d3be62ddf2 Bitcode: Add SimpleBitstreamCursor::getPointerToByte, etc.
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.

llvm-svn: 264546
2016-03-27 22:45:25 +00:00
Duncan P. N. Exon Smith d766d136ce Bitcode: Split out SimpleBitstreamCursor
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.

llvm-svn: 264545
2016-03-27 22:40:55 +00:00
Duncan P. N. Exon Smith fc8110041f Revert "Bitcode: Collect all MDString records into a single blob"
This reverts commit r264409 since it failed to bootstrap:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/

llvm-svn: 264410
2016-03-25 15:22:27 +00:00
Duncan P. N. Exon Smith fdbf0a5af8 Bitcode: Collect all MDString records into a single blob
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.

llvm-svn: 264409
2016-03-25 14:40:18 +00:00
Duncan P. N. Exon Smith 68f5624356 Bitcode: Stop using MODULE_CODE_METADATA_VALUES
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.

llvm-svn: 264378
2016-03-25 01:29:50 +00:00
Duncan P. N. Exon Smith efe16c8eb4 IR: Stop upgrading !llvm.loop attachments via MDString
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.

llvm-svn: 264373
2016-03-25 00:56:13 +00:00
Justin Bogner ae341c6e9b Bitcode: Error out instead of crashing on corrupt metadata
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.

llvm-svn: 263742
2016-03-17 20:12:06 +00:00
Chris Bieneman 671d0dda7d Upgrade TBAA *before* upgrading intrinsics
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

llvm-svn: 263673
2016-03-16 23:17:54 +00:00
Teresa Johnson b43027d1e0 Move global ID computation from Function to GlobalValue (NFC)
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.

llvm-svn: 263524
2016-03-15 02:13:19 +00:00
Teresa Johnson 26ab5772b0 [ThinLTO] Renaming of function index to module summary index (NFC)
(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.

llvm-svn: 263513
2016-03-15 00:04:37 +00:00
Teresa Johnson cec0cae313 Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"
This reverts commit r263490. Missed a file.

llvm-svn: 263493
2016-03-14 21:18:10 +00:00
Teresa Johnson 892920b358 [ThinLTO] Renaming of function index to module summary index (NFC)
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.

llvm-svn: 263490
2016-03-14 21:05:56 +00:00
Teresa Johnson 76a1c1d0ba [ThinLTO] Support for reference graph in per-module and combined summary.
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

llvm-svn: 263275
2016-03-11 18:52:24 +00:00
Mehdi Amini 67dfe09da4 Bitcode reader: Inline readAbbreviatedField in readRecord and move the enclosing loop in each case (NFC)
Summary: This make readRecord 20% faster, measured on an LTO build

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D17911

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262811
2016-03-07 00:38:09 +00:00
Teresa Johnson bbe0545061 [ThinLTO] Add missing breaks when parsing summaries (NFC)
This wasn't causing a correctness issue, but was causing extra duplicate
entries to be added to the SummaryMap.

llvm-svn: 261757
2016-02-24 17:57:28 +00:00
Teresa Johnson e1164de5d0 Restore "[ThinLTO] Use MD5 hash in function index." with fix
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.

llvm-svn: 260442
2016-02-10 21:55:02 +00:00
Teresa Johnson 89f38fb5cc Revert "[ThinLTO] Use MD5 hash in function index." due to bot failure
This reverts commit r260408. Bot failure that I need to investigate.

llvm-svn: 260412
2016-02-10 19:11:15 +00:00
Teresa Johnson 0919a84071 [ThinLTO] Use MD5 hash in function index.
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

llvm-svn: 260408
2016-02-10 18:57:54 +00:00
Teresa Johnson 79d4e2f3a5 Fix VST_CODE_* bitcode id comments (NFC)
llvm-svn: 260382
2016-02-10 15:02:51 +00:00
Teresa Johnson 5e22e4461d [ThinLTO] Include linkage type in function summary
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

llvm-svn: 259993
2016-02-06 16:07:35 +00:00
Chris Bieneman e49730d4ba Remove autoconf support
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

llvm-svn: 258861
2016-01-26 21:29:08 +00:00
Eugene Zelenko 6ac3f739ca Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; other minor fixes.
Differential revision: reviews.llvm.org/D16568

llvm-svn: 258831
2016-01-26 18:48:36 +00:00
Teresa Johnson 6f508afce1 [ThinLTO] Avoid unnecesary hash lookups during metadata linking (NFC)
Replace sequences of count() followed by operator[] with either
find() or insert(), depending on the context.

llvm-svn: 258405
2016-01-21 16:46:40 +00:00
George Burgess IV 1030d68e48 Fix typo in an error string. NFC.
llvm-svn: 258357
2016-01-20 22:15:23 +00:00
Rafael Espindola 257a35368f Bring back "Assert that we have all use/users in the getters."
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.

llvm-svn: 257920
2016-01-15 19:00:20 +00:00
Michael Zolotukhin 65c0120193 Revert "Assert that we have all use/users in the getters."
This reverts commit fdb838f3f8a8b6896bbbd5285555874eb3b748eb.

llvm-svn: 257751
2016-01-14 09:02:45 +00:00
Justin Bogner a43eacbf9e Bitcode: Fix reading and writing of ConstantDataVectors of halfs
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.

llvm-svn: 256982
2016-01-06 22:31:32 +00:00
Teresa Johnson cc428573a2 Ensure MDNode used as key in metadata linking map cannot be RAUWed
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.

llvm-svn: 256648
2015-12-30 19:32:24 +00:00
Teresa Johnson 26aa93586a [ThinLTO] Check MDNode values saved for metadata linking (NFC)
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.

llvm-svn: 256646
2015-12-30 19:13:57 +00:00
Teresa Johnson 61b406ec75 Rename MDValue* to Metadata* (NFC)
Renamed MDValue* to Metadata*, and MDValueToValIDMap to MetadataToIDs,
as per review for r255909.

llvm-svn: 256593
2015-12-29 23:00:22 +00:00
Teresa Johnson 3470295967 Remove overly strict new assert in BitcodeReader.
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.

llvm-svn: 256161
2015-12-21 15:38:13 +00:00
Rafael Espindola e01e363fd9 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.

llvm-svn: 256105
2015-12-19 20:03:23 +00:00
Rafael Espindola 2339ffed97 Deprecate a few C APIs.
This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule

They are replaced with the functions with a 2 suffix which do not record
a diagnostic.

llvm-svn: 256065
2015-12-18 23:46:42 +00:00
Rafael Espindola 79753a07a6 Remove redundant argument. NFC.
llvm-svn: 256031
2015-12-18 21:18:57 +00:00
Rafael Espindola c4a03483f4 Drop materializeAllPermanently.
This inlines materializeAll into the only caller
(materializeAllPermanently) and renames materializeAllPermanently to
just materializeAll.

llvm-svn: 256024
2015-12-18 20:13:39 +00:00
Rafael Espindola 18c63b0f18 Drop support for dematerializing.
It was only used on lib/Linker and the use was "dead" since it was used on a
function the IRMover had just moved.

llvm-svn: 256019
2015-12-18 19:57:26 +00:00
Rafael Espindola d7f9c250df clang-format to reduce diff in another patch.
llvm-svn: 255999
2015-12-18 14:06:34 +00:00
Rafael Espindola f382b8836a Fix error handling in LLVMGetBitcodeModuleInContext.
It was not setting OutMessage.

llvm-svn: 255998
2015-12-18 13:58:05 +00:00
Eric Christopher a6b96004b5 Reorganize the C API headers to improve build times.
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.

llvm-svn: 255965
2015-12-18 01:46:52 +00:00
Rafael Espindola 776e458d81 Drop function that are deprecated since 2010.
These functions were deprecated in r97608.

llvm-svn: 255927
2015-12-17 21:16:12 +00:00
Teresa Johnson e5a6191732 [ThinLTO] Metadata linking for imported functions
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

llvm-svn: 255909
2015-12-17 17:14:09 +00:00
Vaivaswatha Nagaraj fb3f4907c0 Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes
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

llvm-svn: 255778
2015-12-16 16:16:19 +00:00
Rafael Espindola 9d2bfc4874 Use diagnostic handler in the LLVMContext
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.

llvm-svn: 255571
2015-12-14 23:17:03 +00:00
Sanjay Patel fa54acedd1 add fast-math-flags to 'call' instructions (PR21290)
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

llvm-svn: 255555
2015-12-14 21:59:03 +00:00
David Majnemer bbfc7219ef [IR] Remove terminatepad
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

llvm-svn: 255522
2015-12-14 18:34:23 +00:00
David Majnemer 8a1c45d6e8 [IR] Reformulate LLVM's EH funclet IR
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

llvm-svn: 255422
2015-12-12 05:38:55 +00:00
Amjad Aboud a9bcf16ebc Macro debug info support in LLVM IR
Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros.

Differential Revision: http://reviews.llvm.org/D14687

llvm-svn: 255245
2015-12-10 12:56:35 +00:00
Mehdi Amini 9abe1089c7 Remove "ExportingModule" from ThinLTO Index (NFC)
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>
llvm-svn: 254581
2015-12-03 02:37:23 +00:00
Teresa Johnson 6290dbc0f7 [ThinLTO] Handle bitcode without function summary sections gracefully
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

llvm-svn: 253796
2015-11-21 21:55:48 +00:00
Teresa Johnson 16e2a9eeb6 Move new assert to correct location
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.

llvm-svn: 253762
2015-11-21 03:51:23 +00:00
Teresa Johnson d4d3dfd8ef [ThinLTO] Add MODULE_CODE_METADATA_VALUES record
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

llvm-svn: 253668
2015-11-20 14:51:27 +00:00
Mehdi Amini 354f520fbc Do not require a Context to extract the FunctionIndex from Bitcode (NFC)
The LLVMContext was only used for Diagnostic. Pass a DiagnosticHandler
instead.

Differential Revision: http://reviews.llvm.org/D14794

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 253540
2015-11-19 05:52:29 +00:00
Sanjoy Das f79d3449c5 [OperandBundles] Tighten OperandBundleDef's interface; NFC
llvm-svn: 253446
2015-11-18 08:30:07 +00:00
Teresa Johnson 12545075f0 Use a different block id for block of metadata kind records
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

llvm-svn: 253154
2015-11-15 02:00:09 +00:00
Mehdi Amini 3383ccc400 Add a method to the BitcodeReader to parse only the identification block
Summary: Mimic parseTriple(); and exposes it to LTOModule.cpp

Reviewers: dexonsmith, rafael

Subscribers: llvm-commits

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 252442
2015-11-09 02:46:41 +00:00
Akira Hatanaka 97cb397132 [Bitcode] Add enums for call instruction markers and flags. NFC.
This commit adds enums in LLVMBitCodes.h to improve readability and
maintainability. This is a follow-up to r252368 which was discussed
here:

http://reviews.llvm.org/D12923

llvm-svn: 252395
2015-11-07 02:48:49 +00:00
Akira Hatanaka 5cfcce12eb Add 'notail' marker for call instructions.
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

llvm-svn: 252368
2015-11-06 23:55:38 +00:00
James Molloy e6f87ca812 Add a new attribute: norecurse
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.

llvm-svn: 252282
2015-11-06 10:32:53 +00:00
Peter Collingbourne d4bff30370 DI: Reverse direction of subprogram -> function edge.
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

llvm-svn: 252219
2015-11-05 22:03:56 +00:00
Filipe Cabecinhas a2b0ac40cf Error out when faced with value names containing '\0'
Bug found with afl-fuzz.

llvm-svn: 252048
2015-11-04 14:53:36 +00:00
Filipe Cabecinhas 7aae2f23c8 Don't assert if materializing before seeing any function bodies
This assert was reachable from user input. A minimized test case (no
FUNCTION_BLOCK_ID record) is attached.

Bug found with afl-fuzz

llvm-svn: 251910
2015-11-03 13:48:26 +00:00
Filipe Cabecinhas f3e167af4b Don't use Twine objects after their lifetimes end.
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.

llvm-svn: 251909
2015-11-03 13:48:21 +00:00
Teresa Johnson c7ed52f2ba Restore "Support for ThinLTO function importing and symbol linking."
This restores commit r251837, with the new library dependence added to
llvm-link/Makefile to address bot failures.

llvm-svn: 251866
2015-11-03 00:14:15 +00:00
Teresa Johnson 227a923140 Revert "Support for ThinLTO function importing and symbol linking."
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?

llvm-svn: 251841
2015-11-02 22:17:32 +00:00
Teresa Johnson b1d4a39990 Support for ThinLTO function importing and symbol linking.
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

llvm-svn: 251837
2015-11-02 21:39:10 +00:00
Teresa Johnson f72278f051 Clang format a few prior patches (NFC)
I had clang formatted my earlier patches using the wrong style.
Reformatted with the LLVM style.

llvm-svn: 251812
2015-11-02 18:02:11 +00:00
Filipe Cabecinhas 14323e02e6 Revert "Don't assert if materializing before seeing any function bodies"
This reverts r251667 since it broke the bots.

llvm-svn: 251671
2015-10-30 00:00:58 +00:00
Filipe Cabecinhas bcfd1f0c56 Don't assert if materializing before seeing any function bodies
This assert was reachable from user input. A minimized test case (no
FUNCTION_BLOCK_ID record) is attached.

Bug found with afl-fuzz

llvm-svn: 251667
2015-10-29 23:37:28 +00:00
Peter Collingbourne 128a9760e0 Bitcode: Fix more unsigned integer overflow bugs.
llvm-svn: 251464
2015-10-27 23:01:25 +00:00
Vedant Kumar ad6d6e7423 [IR] Limit bits used for CallingConv::ID, update tests
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

llvm-svn: 251452
2015-10-27 21:17:06 +00:00
Oleksiy Vyalov 6c2403f3fa Use Twin instead of std::to_string.
http://reviews.llvm.org/D14095

llvm-svn: 251365
2015-10-26 22:37:36 +00:00
Mehdi Amini 5d303285b9 Add an (optional) identification block in the bitcode
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>
llvm-svn: 251325
2015-10-26 18:37:00 +00:00
Teresa Johnson c8a8a5e2ae Silence Visual C++ warning in function summary parsing code (NFC)
llvm-svn: 250929
2015-10-21 19:25:14 +00:00
Duncan P. N. Exon Smith fb1743a32e BitcodeReader: Remove ilist iterator implicit conversions, NFC
Get LLVMBitReader building without relying on `ilist_iterator` implicit
conversions.

llvm-svn: 250181
2015-10-13 16:48:55 +00:00
Teresa Johnson 1493ad9c24 Fix PR25101 - Handle anonymous functions without VST entries
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

llvm-svn: 249947
2015-10-10 14:18:36 +00:00
Filipe Cabecinhas b70fd8719e Make sure the CastInst is valid before trying to create it
Bug found with afl-fuzz.

llvm-svn: 249396
2015-10-06 12:37:54 +00:00
Teresa Johnson 19f517a7d7 Remove unused private field introduced by r249270.
llvm-svn: 249277
2015-10-04 15:00:55 +00:00
Teresa Johnson 403a787e03 Support for function summary index bitcode sections and files.
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

llvm-svn: 249270
2015-10-04 14:33:43 +00:00
Sanjoy Das b513a9fa4f [Bitcode][Asm] Teach LLVM to read and write operand bundles.
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

llvm-svn: 248551
2015-09-24 23:34:52 +00:00
Aaron Ballman 2d0f38c5fb Silencing a -Wsign-compare warning; NFC.
llvm-svn: 247986
2015-09-18 13:31:42 +00:00
David Blaikie 6a51dbdb3c [opaque pointer types] Add an explicit pointee type to alias records in the IR
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.

llvm-svn: 247952
2015-09-17 22:18:59 +00:00
Teresa Johnson ff642b9b84 Restore "Function bitcode index in Value Symbol Table and lazy reading support"
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

llvm-svn: 247927
2015-09-17 20:12:00 +00:00
Teresa Johnson 2e98d57ad4 Revert "Function bitcode index in Value Symbol Table and lazy reading support"
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.

llvm-svn: 247898
2015-09-17 16:19:10 +00:00
Teresa Johnson b77b1f8a0c Function bitcode index in Value Symbol Table and lazy reading support
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

llvm-svn: 247894
2015-09-17 15:52:30 +00:00
David Blaikie 16a2f3e302 Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type rather than decomposing it into pointee type + address space"
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.

llvm-svn: 247585
2015-09-14 18:01:59 +00:00
Joseph Tremoulet 9ce71f76b9 [WinEH] Add cleanupendpad instruction
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

llvm-svn: 246751
2015-09-03 09:09:43 +00:00
Filipe Cabecinhas 984fefdd81 [BitcodeReader] Ensure we can read constant vector selects with an i1 condition
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

llvm-svn: 246459
2015-08-31 18:00:30 +00:00
Karl Schimpf 36440082f8 Change comment to verify commit accesss.
llvm-svn: 246451
2015-08-31 16:43:55 +00:00
Duncan P. N. Exon Smith 814b8e91c7 DI: Require subprogram definitions to be distinct
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.

llvm-svn: 246327
2015-08-28 20:26:49 +00:00
David Majnemer b01aa9f794 [IR] Cleanup EH instructions a little bit
Just a cosmetic change, no functionality change is intended.

llvm-svn: 245818
2015-08-23 19:22:31 +00:00
Joseph Tremoulet 8220bcc570 [WinEH] Require token linkage in EH pad/ret signatures
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

llvm-svn: 245797
2015-08-23 00:26:33 +00:00
David Majnemer 0bc0eef71c [IR] Give catchret an optional 'return value' operand
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.

llvm-svn: 245149
2015-08-15 02:46:08 +00:00
David Majnemer b611e3f50e [IR] Add token types
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

llvm-svn: 245029
2015-08-14 05:09:07 +00:00
Duncan P. N. Exon Smith 55ca964e94 DI: Disallow uniquable DICompileUnits
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.

llvm-svn: 243885
2015-08-03 17:26:41 +00:00
Duncan P. N. Exon Smith ed013cd221 DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variable
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.)

llvm-svn: 243774
2015-07-31 18:58:39 +00:00
David Majnemer 654e130b6e New EH representation for MSVC compatibility
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

llvm-svn: 243766
2015-07-31 17:58:14 +00:00
Bob Wilson 043ee65ef3 Reserve some constant values for the Swift calling convention.
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.

llvm-svn: 243379
2015-07-28 04:05:45 +00:00
Igor Laevsky 39d662f7ba Add argmemonly attribute.
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

llvm-svn: 241979
2015-07-11 10:30:36 +00:00
James Molloy 88eb535b2d Add support for fast-math flags to the FCmp instruction.
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.

llvm-svn: 241901
2015-07-10 12:52:00 +00:00
David Majnemer db82d2f338 Revert the new EH instructions
This reverts commits r241888-r241891, I didn't mean to commit them.

llvm-svn: 241893
2015-07-10 07:15:17 +00:00
David Majnemer ae2ffc8a8c New EH representation for MSVC compatibility
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

llvm-svn: 241888
2015-07-10 07:00:44 +00:00
Filipe Cabecinhas 0011c58444 Remove always-true comparison, NFC.
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

llvm-svn: 241369
2015-07-03 20:12:01 +00:00
Rafael Espindola d48e54c5ea Avoid a use after free.
llvm-svn: 241345
2015-07-03 12:20:34 +00:00
Rafael Espindola 4e7212177f Fix for PR23310: llvm-dis crashes when trying to upgrade an intrinsic.
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.

llvm-svn: 241281
2015-07-02 16:22:40 +00:00
Rafael Espindola 86e3340f31 Rangify some loops.
Patch by Philip Pfaffe!

llvm-svn: 241279
2015-07-02 15:55:09 +00:00
Adrian Prantl ab1243fe6c Add a DIModule metadata node to the IR.
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

llvm-svn: 241017
2015-06-29 23:03:47 +00:00
Alexander Kornienko f00654e31b Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)
Apparently, the style needs to be agreed upon first.

llvm-svn: 240390
2015-06-23 09:49:53 +00:00
Rafael Espindola 1c863ca3ea Remove the IsStreamed member variable.
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.

llvm-svn: 240305
2015-06-22 18:06:15 +00:00
Alexander Kornienko 70bc5f1398 Fixed/added namespace ending comments using clang-tidy. NFC
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!

llvm-svn: 240137
2015-06-19 15:57:42 +00:00
David Majnemer 7fddeccb8b Move the personality function from LandingPadInst to Function
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

llvm-svn: 239940
2015-06-17 20:52:32 +00:00
Rafael Espindola 456baad24d Handle forward referenced function when streaming bitcode.
Without this the included unit test would assert in

  assert(BasicBlockFwdRefs.empty() && "Unresolved blockaddress fwd references");

llvm-svn: 239871
2015-06-17 01:15:47 +00:00
Rafael Espindola 728074b73c Handle MaterializeAll in getLazyBitcodeModuleImpl. NFC.
This just handles both cases in the same place.

Extracted from a patch by Karl Schimpf.

llvm-svn: 239870
2015-06-17 00:40:56 +00:00
Rafael Espindola 1aabf982bc Use std::unique_ptr to manage the DataStreamer in bitcode parsing.
We were already deleting it, this just makes it explicit.

llvm-svn: 239867
2015-06-16 23:29:49 +00:00
Rafael Espindola dcd1dca275 Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.
llvm-svn: 239858
2015-06-16 22:27:55 +00:00
Rafael Espindola c6afe0d4e9 Improve handling of end of file in the bitcode reader.
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.

llvm-svn: 239845
2015-06-16 20:03:39 +00:00
Peter Collingbourne 82437bf7a5 Protection against stack-based memory corruption errors using SafeStack
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

llvm-svn: 239761
2015-06-15 21:07:11 +00:00
Rafael Espindola 64a27fb801 Don't indent inside a namespace. NFC.
llvm-svn: 239760
2015-06-15 21:04:27 +00:00
Rafael Espindola 6ace68554d Replace @ with the more common \. NFC.
llvm-svn: 239759
2015-06-15 21:02:49 +00:00
Rafael Espindola cbdcb50554 Don't repeat names in comments and start functions with a lower case letter.
llvm-svn: 239756
2015-06-15 20:55:37 +00:00
Rafael Espindola 4223a1f811 Cleanup the constructor of BitcodeReader. NFC.
Use the same argument names as the members.
Use default member initializes.

Extracted from a patch by Karl Schimpf.

llvm-svn: 239749
2015-06-15 20:08:17 +00:00
Yaron Keren ef5e7addb3 Rangify two for loops in BitcodeReader.cpp.
llvm-svn: 239627
2015-06-12 18:13:20 +00:00
Filipe Cabecinhas a911af0e8c Use early return idiom. NFC
llvm-svn: 239228
2015-06-06 20:44:53 +00:00
Filipe Cabecinhas da86b6d409 [BitcodeReader] Diagnose type mismatches with aliases
Bug found with AFL fuzz.

llvm-svn: 238895
2015-06-03 01:30:13 +00:00
Filipe Cabecinhas 8e42190d20 [BitcodeReader] Check vector size before trying to create a VectorType
Bug found with AFL fuzz

llvm-svn: 238891
2015-06-03 00:05:30 +00:00
Filipe Cabecinhas 14e686774d [BitcodeReader] Change an assert to a call to a call to Error()
It's reachable from user input.

Bug found with AFL fuzz.

llvm-svn: 238633
2015-05-30 00:17:20 +00:00
Benjamin Kramer f5e2fc474d Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types
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.

llvm-svn: 238602
2015-05-29 19:43:39 +00:00
Filipe Cabecinhas 6a92a3fe34 [BitcodeReader] Change assert to report_fatal_error
It can be triggered by user input.

Bug found with AFL fuzz.

llvm-svn: 238272
2015-05-27 01:05:40 +00:00
Filipe Cabecinhas 8cd99e9a5a [BitstreamReader] Make sure the Array operand type is an encoding
Bug found with AFL fuzz.

llvm-svn: 238269
2015-05-27 00:48:43 +00:00
Filipe Cabecinhas a872a476cb clang-format a couple of lines
llvm-svn: 238268
2015-05-27 00:48:37 +00:00
Filipe Cabecinhas bc6a909384 [BitcodeReader] Make sure abbrev records have at least one operand (record code)
Bug found with AFL fuzz.

llvm-svn: 238265
2015-05-26 23:52:21 +00:00
Owen Anderson 85fa7d5037 Add initial support for the convergent attribute.
llvm-svn: 238264
2015-05-26 23:48:40 +00:00
Filipe Cabecinhas 0eb8a59a67 [BitcodeReader] Sanity check on Comdat ID
Shouldn't be an assert, since user input can trigger it.

Bug found with AFL fuzz.

llvm-svn: 238261
2015-05-26 23:00:56 +00:00
Rafael Espindola e7134b2d78 Simplify boolean conditional return statements.
Patch by Richard <legalize@xmission.com>

llvm-svn: 238134
2015-05-25 13:50:21 +00:00
Adrian Prantl 1f599f9f65 IR / debug info: Add a DWOId field to DICompileUnit,
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

llvm-svn: 237949
2015-05-21 20:37:30 +00:00
Filipe Cabecinhas 32af542194 [BitcodeReader] Error out if we read an invalid function argument type
Bug found with AFL fuzz.

llvm-svn: 237650
2015-05-19 01:21:06 +00:00
Filipe Cabecinhas f3fa99c48e [BitcodeReader] It's a malformed block if CodeLenWidth is too big
Bug found with AFL fuzz.

llvm-svn: 237646
2015-05-19 00:34:17 +00:00
Filipe Cabecinhas 4708a02a78 [BitcodeReader] Make sure the type of the inserted value matches the type of the aggregate at those indices
Bug found with AFL-fuzz.

llvm-svn: 237628
2015-05-18 22:27:11 +00:00
Filipe Cabecinhas 11bb8495f6 Extract the load/store type verification to a separate function.
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

llvm-svn: 237619
2015-05-18 21:48:55 +00:00
Filipe Cabecinhas 1c299d05e6 [BitcodeReader] Don't allow INSERTVAL/EXTRACTVAL with 0 indices
This would trigger an assertion later.

Bug found with AFL fuzz.

llvm-svn: 237494
2015-05-16 00:33:12 +00:00
Filipe Cabecinhas 1d9f642cc8 Remove redundant checks. NFC
llvm-svn: 237488
2015-05-15 23:57:13 +00:00
Eric Christopher 97cb56572a While in GlobalValue fix the function(s) that don't follow the
naming convention and update users.

llvm-svn: 237461
2015-05-15 18:20:14 +00:00
David Blaikie 60310f2720 [opaque pointer type] Explicit pointee type for GEPOperator/GEPConstantExpr.
Also a couple of other changes to avoid use of
PointerType::getElementType here & there too.

llvm-svn: 236799
2015-05-08 00:42:26 +00:00
Filipe Cabecinhas f8a16a952d Don't overflow GCTable
Summary: Bug found with AFL fuzz.

Reviewers: rafael, dexonsmith

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9361

llvm-svn: 236200
2015-04-30 04:09:41 +00:00
Filipe Cabecinhas 9a19e56306 Make sure Op->getType() is a PointerType before we cast<> it.
Bug found with AFL fuzz.

llvm-svn: 236193
2015-04-30 01:13:31 +00:00
Filipe Cabecinhas bad0779f63 Make sure we don't resize(0) when we get a fwdref with Idx == UINT_MAX
Make it an error instead.

Bug found with AFL fuzz.

llvm-svn: 236190
2015-04-30 00:52:42 +00:00
David Blaikie f64246be72 [opaque pointer type] Pass GlobalAlias the actual pointer type rather than decomposing it into pointee type + address space
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.

llvm-svn: 236160
2015-04-29 21:22:39 +00:00
Duncan P. N. Exon Smith a9308c49ef IR: Give 'DI' prefix to debug info metadata
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.

llvm-svn: 236120
2015-04-29 16:38:44 +00:00
Filipe Cabecinhas 6fe8aabd45 Use an "early return" idiom for the error case. NFC
llvm-svn: 236080
2015-04-29 02:36:08 +00:00
Filipe Cabecinhas d8a1bcd0ad Check that we have a valid PointerType element type before calling get()
Same as r236073 but for PointerType.

Bug found with AFL fuzz.

llvm-svn: 236079
2015-04-29 02:27:28 +00:00
Filipe Cabecinhas 52d42c725a Use the ArrayType member function for array element types.
ArrayType and StructType accept the same types, so no test.

llvm-svn: 236078
2015-04-29 02:27:21 +00:00
Filipe Cabecinhas 1351cba720 Turn an assert into report_fatal_error since it's reachable based on user input
Bug found with AFL fuzz.

llvm-svn: 236076
2015-04-29 01:58:31 +00:00
Filipe Cabecinhas f15fb032ef Make sure that isValidElementType(Type) before calling {Array,Struct}Type::get(Type)
Bug found with AFL fuzz.

llvm-svn: 236073
2015-04-29 01:27:01 +00:00
Filipe Cabecinhas b435d0f439 Relax an assert when there's a type mismatch in forward references
Summary:
We don't seem to need to assert here, since this function's callers expect
to get a nullptr on error. This way we don't assert on user input.

Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9308

llvm-svn: 236027
2015-04-28 20:18:47 +00:00
David Blaikie bdb4910202 [opaque pointer type] Encode the allocated type of an alloca rather than its pointer result type.
llvm-svn: 235998
2015-04-28 16:51:01 +00:00
David Blaikie 2a661cd062 [opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'
As a space optimization, this instruction would just encode the pointer
type of the first operand and use the knowledge that the second and
third operands would be of the pointee type of the first. When typed
pointers go away, this assumption will no longer be available - so
encode the type of the second operand explicitly and rely on that for
the third.

Test case added to demonstrate the backwards compatibility concern,
which only comes up when the definition of the second operand comes
after the use (hence the weird basic block sequence) - at which point
the type needs to be explicitly encoded in the bitcode and the record
length changes to accommodate this.

llvm-svn: 235966
2015-04-28 04:30:29 +00:00
David Blaikie 1a848da518 [opaque pointer type] encode the pointee type of global variables
Use a few extra bits in the const field (after widening it from a fixed
single bit) to stash the address space which is no longer provided by
the type (and an extra bit in there to specify that we're using that new
encoding).

llvm-svn: 235911
2015-04-27 19:58:56 +00:00
Duncan P. N. Exon Smith 3d4cd756b6 IR: Add assembly/bitcode support for function metadata attachments
Add serialization support for function metadata attachments (added in
r235783).  The syntax is:

    define @foo() !attach !0 {

Metadata attachments are only allowed on functions with bodies.  Since
they come before the `{`, they're not really part of the body; since
they require a body, they're not really part of the header.  In
`LLParser` I gave them a separate function called from `ParseDefine()`,
`ParseOptionalFunctionMetadata()`.

In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by
instructions.  Instruction metadata attachments are included in a
special "attachment" block at the end of a `Function`.  The attachment
records are laid out like this:

    InstID (KindID MetadataID)+

Note that these records always have an odd number of fields.  The new
code takes advantage of this to recognize function attachments (which
don't need an instruction ID):

    (KindID MetadataID)+

This means we can use the same attachment block already used for
instructions.

This is part of PR23340.

llvm-svn: 235785
2015-04-24 22:04:41 +00:00
David Blaikie 5ea1f7b744 [opaque pointer type] bitcode: add explicit callee type to invoke instructions
llvm-svn: 235735
2015-04-24 18:06:06 +00:00
Filipe Cabecinhas ff1e234fb8 [BitcodeReader] Fix asserts when we read a non-vector type for insert/extract/shuffle
Added some additional checking for vector types + tests.

Bug found with AFL fuzz.

llvm-svn: 235710
2015-04-24 11:30:15 +00:00
David Blaikie 348de69a30 Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst
(reverted in r235533)

Original commit message:

"Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)"

The remapping done in ValueMapper for LTO was insufficient as the types
weren't correctly mapped (though I was using the post-mapped operands,
some of those operands might not have been mapped yet so the type
wouldn't be post-mapped yet). Instead use the pre-mapped type and
explicitly map all the types.

llvm-svn: 235651
2015-04-23 21:36:23 +00:00
Filipe Cabecinhas 6621cb7478 Be more strict about the operand for the array type in BitcodeReader
Summary: Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9016

llvm-svn: 235596
2015-04-23 13:38:21 +00:00
Filipe Cabecinhas ee48feadfd Verify sizes when trying to read a BitcodeAbbrevOp
Summary:
Make sure the abbrev operands are valid and that we can read/skip them
afterwards.

Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9030

llvm-svn: 235595
2015-04-23 13:25:35 +00:00
David Blaikie d2db881e85 Revert "[opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst"
This reverts commit r235458.

It looks like this might be breaking something LTO-ish. Looking into it
& will recommit with a fix/test case/etc once I've got more to go on.

llvm-svn: 235533
2015-04-22 18:16:49 +00:00
Filipe Cabecinhas ea79c5b4f7 Have more strict type checks when creating BinOp nodes in BitcodeReader
Summary: Bug found with AFL.

Reviewers: rafael, bkramer

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9015

llvm-svn: 235489
2015-04-22 09:06:21 +00:00
David Blaikie 50a0615264 [opaque pointer types] Serialize the value type for atomic store instructions
Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add the extra type
information that would be missing.

llvm-svn: 235475
2015-04-22 04:14:46 +00:00
David Blaikie 612ddbfde0 [opaque pointer types] Serialize the value type for store instructions
Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add the extra type
information that would be missing.

Storeatomic coming soon.

llvm-svn: 235474
2015-04-22 04:14:42 +00:00
David Blaikie 506993636e [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst
Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)

llvm-svn: 235458
2015-04-21 23:26:57 +00:00
David Blaikie b7a0298731 [opaque pointer types] Use the pointee type loaded from bitcode when constructing a LoadInst
Now (with a few carefully placed suppressions relating to general type
serialization, etc) we can round trip a simple load through bitcode and
textual IR without calling getElementType on a PointerType.

llvm-svn: 235221
2015-04-17 19:56:21 +00:00
David Blaikie 561a157233 [opaque pointer type] Serialize the type of an llvm::Function as a function type rather than a function pointer type
llvm-svn: 235200
2015-04-17 16:28:26 +00:00
David Blaikie dbe6e0f171 [opaque pointer type] Explicit pointee type for call instruction
Use an extra bit in the CCInfo to flag the newer version of the
instructiont hat includes the type explicitly.

Tested the newer error cases I added, but didn't add tests for the finer
granularity improvements to existing error paths.

llvm-svn: 235160
2015-04-17 06:40:14 +00:00
Sanjoy Das 31ea6d1590 [IR] Introduce a dereferenceable_or_null(N) attribute.
Summary:
If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it
is either `null` or `dereferenceable(N)` or both.  This change only
introduces the attribute and adds a token test case for the `llvm-as`
/ `llvm-dis`.  It does not hook up other parts of the optimizer to
actually exploit the attribute -- those changes will come later.

For pointers in address space 0, `dereferenceable(N)` is now exactly
equivalent to `dereferenceable_or_null(N)` && `nonnull`.  For other
address spaces, `dereferenceable(N)` is potentially weaker than
`dereferenceable_or_null(N)` && `nonnull` (since we could have a null
`dereferenceable(N)` pointer).

The motivating case for this change is Java (and other managed
languages), where pointers are either `null` or dereferenceable up to
some usually known-at-compile-time constant offset.

Reviewers: rafael, hfinkel

Reviewed By: hfinkel

Subscribers: nicholas, llvm-commits

Differential Revision: http://reviews.llvm.org/D8650

llvm-svn: 235132
2015-04-16 20:29:50 +00:00
Duncan P. N. Exon Smith 62e0f454a0 DebugInfo: Remove 'inlinedAt:' field from MDLocalVariable
Remove 'inlinedAt:' from MDLocalVariable.  Besides saving some memory
(variables with it seem to be single largest `Metadata` contributer to
memory usage right now in -g -flto builds), this stops optimization and
backend passes from having to change local variables.

The 'inlinedAt:' field was used by the backend in two ways:

 1. To tell the backend whether and into what a variable was inlined.
 2. To create a unique id for each inlined variable.

Instead, rely on the 'inlinedAt:' field of the intrinsic's `!dbg`
attachment, and change the DWARF backend to use a typedef called
`InlinedVariable` which is `std::pair<MDLocalVariable*, MDLocation*>`.
This `DebugLoc` is already passed reliably through the backend (as
verified by r234021).

This commit removes the check from r234021, but I added a new check
(that will survive) in r235048, and changed the `DIBuilder` API in
r235041 to require a `!dbg` attachment whose 'scope:` is in the same
`MDSubprogram` as the variable's.

If this breaks your out-of-tree testcases, perhaps the script I used
(mdlocalvariable-drop-inlinedat.sh) will help; I'll attach it to PR22778
in a moment.

llvm-svn: 235050
2015-04-15 22:29:27 +00:00
Filipe Cabecinhas 2e206eb65f Revert "Verify sizes when trying to read a VBR"
This reverts r234984 since it seems to break some bots (most of them
seemed arm*-selfhost).

llvm-svn: 234998
2015-04-15 11:10:17 +00:00
Filipe Cabecinhas 7dc896fcce Verify sizes when trying to read a VBR
Also added an assert to ReadVBR64.

llvm-svn: 234984
2015-04-15 08:48:08 +00:00
Filipe Cabecinhas 225542713b Error out of ParseBitcodeInto(Module*) if we haven't read a Module
Summary:
Without this check the following case failed:

Skip a SubBlock which is not a MODULE_BLOCK_ID nor a BLOCKINFO_BLOCK_ID
Got to end of file

TheModule would still be == nullptr, and we would subsequentially fail
when materializing the Module (assert at the start of
BitcodeReader::MaterializeModule).

Bug found with AFL.

Reviewers: dexonsmith, rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9014

llvm-svn: 234887
2015-04-14 14:07:15 +00:00
Alexander Kornienko f817c1cb9a Use 'override/final' instead of 'virtual' for overridden methods
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' \
    -j=32 -fix -format

http://reviews.llvm.org/D8925

llvm-svn: 234679
2015-04-11 02:11:45 +00:00
David Blaikie 4a2e73b066 [opaque pointer type] API migration for GEP constant factories
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.

llvm-svn: 233938
2015-04-02 18:55:32 +00:00
Rafael Espindola 468b8688ce git-clang-format r233603.
Thanks to Meador Inge for noticing.

llvm-svn: 233808
2015-04-01 14:44:59 +00:00
Rafael Espindola 0d68b4c5ed Fix PR23045.
Keep a note in the materializer that we are stripping debug info so that
user doing a lazy read of the module don't hit outdated formats.

Thanks to Duncan for suggesting the fix.

llvm-svn: 233603
2015-03-30 21:36:43 +00:00
Duncan P. N. Exon Smith 264899823f Verifier: Check accessors of MDLocation
Check accessors of `MDLocation`, and change them to `cast<>` down to the
right types.  Also add type-safe factory functions.

All the callers that handle broken code need to use the new versions of
the accessors (`getRawScope()` instead of `getScope()`) that still
return `Metadata*`.  This is also necessary for things like
`MDNodeKeyImpl<MDLocation>` (in LLVMContextImpl.h) that need to unique
the nodes when their operands might still be forward references of the
wrong type.

In the `Value` hierarchy, consumers that handle broken code use
`getOperand()` directly.  However, debug info nodes have a ton of
operands, and their order (even their existence) isn't stable yet.  It's
safer and more maintainable to add an explicit "raw" accessor on the
class itself.

llvm-svn: 233322
2015-03-26 22:05:04 +00:00
Benjamin Kramer cced8bee52 Internalize BitcodeReader. Not used outside of BitcodeReader.cpp.
NFC.

llvm-svn: 232542
2015-03-17 20:40:24 +00:00
David Blaikie 12cf5d70e8 Add testing for mismatched explicit type on a gep operator when loading from bitcode
llvm-svn: 232427
2015-03-16 22:03:50 +00:00
David Blaikie c695cc7e58 Add testing for mismatched explicit type on a load instruction when loading from bitcode
llvm-svn: 232424
2015-03-16 21:48:46 +00:00
David Blaikie 675e8cb09e Test bitcode parsing error-handling for incorrect explicit type
(turns out I had regressed this when sinking handling of this type down
into GetElementPtrInst::Create - since that asserted before the error
handling was performed)

llvm-svn: 232420
2015-03-16 21:35:48 +00:00
David Blaikie 096b1da29d [opaque pointer type] more gep API migration
llvm-svn: 232274
2015-03-14 19:53:33 +00:00
Rafael Espindola cba833a09d Be lazy about loading metadata in IRObjectFile.
This speeds up llvm-ar building lib64/libclangSema.a with debug IR files
from 8.658015807 seconds to just 0.351036519 seconds :-)

llvm-svn: 232221
2015-03-13 21:54:20 +00:00
David Blaikie b9263570a5 [opaque pointer type] Bitcode support for explicit type parameter on the gep operator
This happened to be fairly easy to support backwards compatibility based
on the number of operands (old format had an even number, new format has
one more operand so an odd number).

test/Bitcode/old-aliases.ll already appears to test old gep operators
(if I remove the backwards compatibility in the BitcodeReader, this and
another test fail) so I'm not adding extra test coverage here.

llvm-svn: 232216
2015-03-13 21:03:36 +00:00
David Blaikie 4a5c8c602c Turn assertion into bitcode reading error
I don't think we test invalid bitcode records in any detail, so no test
here - just a change for consistency with existing error checks in
surrounding code.

llvm-svn: 232215
2015-03-13 21:03:34 +00:00
Manman Ren 4a9b0ebe83 Add a parameter for getLazyBitcodeModule to lazily load Metadata.
We only defer loading metadata inside ParseModule when ShouldLazyLoadMetadata
is true and we have not loaded any Metadata block yet.

This commit implements all-or-nothing loading of Metadata. If there is a
request to load any metadata block, we will load all deferred metadata blocks.

We make sure the deferred metadata blocks are loaded before we materialize any
function or a module.

The default value of the added parameter ShouldLazyLoadMetadata for
getLazyBitcodeModule is false, so the default behavior stays the same.

We only set the parameter to true when creating LTOModule in local contexts.
These can only really be used for parsing symbols, so it's unnecessary to ever
load the metadata blocks.

If we are going to enable lazy-loading of Metadata for other usages of
getLazyBitcodeModule, where deferred metadata blocks need to be loaded, we can
expose BitcodeReader::materializeMetadata to Module, similar to
Module::materialize.

rdar://19804575

llvm-svn: 232198
2015-03-13 19:24:30 +00:00
David Blaikie dc3f01e9cf Simplify expressions involving boolean constants with clang-tidy
Patch by Richard (legalize at xmission dot com).

Differential Revision: http://reviews.llvm.org/D8154

llvm-svn: 231617
2015-03-09 01:57:13 +00:00
Benjamin Kramer 0a446fd56c Add missing includes. make_unique proliferated everywhere.
llvm-svn: 230909
2015-03-01 21:28:53 +00:00
Yaron Keren d602c35eca Silence three more variable set but not used warnings, NFC.
llvm-svn: 230853
2015-02-28 15:29:17 +00:00
David Blaikie b5b5efd2d1 [opaque pointer type] Bitcode support for explicit type parameter on GEP.
Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

Differential Revision: http://reviews.llvm.org/D7736

llvm-svn: 230415
2015-02-25 01:08:52 +00:00
David Blaikie 8503565eec [opaque pointer type] bitcode support for explicit type parameter to the load instruction
Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections would be great.

This seems to pass all the tests (check-all, covering clang and llvm) so I
believe that pretty well exercises both the backwards compatibility and common
(same version) compatibility given the number of checked in bitcode files we
already have. Is that a reasonable approach to testing here? Would some more
explicit tests be desired?

1) is this the right way to do back-compat in this case (looking at the number
  of entries in the bitcode record to disambiguate between the old schema and
  the new?)

2) I don't quite understand the logarithm logic to choose the encoding type of
  the type parameter in the abbreviation description, but I found another
  instruction doing the same thing & it seems to work. Is that the right
  approach?

Reviewers: dexonsmith

Differential Revision: http://reviews.llvm.org/D7655

llvm-svn: 230414
2015-02-25 01:07:20 +00:00
JF Bastien 30bf96bfe7 Use common parse routine to read alignment values from bitcode
While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem.

This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic.

Patch by Karl Schimpf (kschimpf@google.com).

llvm-svn: 230180
2015-02-22 19:32:03 +00:00
Duncan P. N. Exon Smith ad6eb127c9 Bitcode: Stop assuming non-null fields
When writing the bitcode serialization for the new debug info hierarchy,
I assumed two fields would never be null.

Drop that assumption, since it's brittle (and crashes the
`BitcodeWriter` if wrong), and is a check better left for the verifier
anyway.  (No need for a bitcode upgrade here, since the new hierarchy is
still not in place.)

The fields in question are `MDCompileUnit::getFile()` and
`MDDerivedType::getBaseType()`, the latter of which isn't null in
test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to
nothing).  While the testcase might have bitrotted, there's no reason
for the bitcode format to rely on non-null for metadata operands.

This also fixes a bug in `AsmWriter` where if the `file:` is null it
isn't emitted (caught by the double-round trip in the testcase I'm
adding) -- this is a required field in `LLParser`.

I'll circle back to ConvertDebugInfo2.  Once the specialized nodes are
in place, I'll be trying to turn the debug info verifier back on by
default (in the newer module pass form committed r206300) and throwing
more logic in there.  If the testcase has bitrotted (as opposed to me
not understanding the schema correctly) I'll fix it then.

llvm-svn: 229960
2015-02-20 03:17:58 +00:00
Duncan P. N. Exon Smith 3d62bbacb1 IR: Drop scope from MDTemplateParameter
Follow-up to r229740, which removed `DITemplate*::getContext()` after my
upgrade script revealed that scopes are always `nullptr` for template
parameters.  This is the other shoe: drop `scope:` from
`MDTemplateParameter` and its two subclasses.  (Note: a bitcode upgrade
would be pointless, since the hierarchy hasn't been moved into place.)

llvm-svn: 229791
2015-02-19 00:37:21 +00:00
Duncan P. N. Exon Smith 060ee625b8 Bitcode: Fix major regression: large files w/ debug info
The metadata/value split introduced a major regression reading large
bitcode files that contain debug info (or other cyclic (non-self
reference) metadata graphs).  For the first time in a while, I dropped
from libLTO.dylib down to `llvm-lto` with a non-trivial bitcode file
(~350MB), and I hit this when reading the result of ld64's `-save-temps`
in `llvm-lto`.

Here's pseudo-code for what was going on:

    read-main-metadata-block:
      for each md:
        if has-fwd-ref: // Only true for cyclic graphs.
          any-fwd-refs <- true
      if any-fwd-refs:
        foreach md:
          resolve-cycles(md) // Handle cycles.

    foreach function:
      read-function-metadata-block: // Such as !alias, !loop
        if any-fwd-refs:
          foreach md: // (all metadata, not just this block)
            resolve-cycles(md) // A no-op, but the loop is expensive!!

This commit resets the `AnyFwdRefs` flag to `false`.  This on its own
was enough to change my Release+Asserts `llvm-lto` time for reading this
bitcode from over 20 minutes (I gave up on it) to 20 seconds.  I've gone
further by tracking the min/max metadata forward-references in a
metadata block.  This protects against a schema that has lots of
functions that each reference their own metadata cycle.

Unfortunately, this regression is in the 3.6 branch as well.

llvm-svn: 229421
2015-02-16 19:18:01 +00:00
Filipe Cabecinhas ecf8f7f49b [Bitcode reader] Fix a few assertions when reading invalid files
Summary:
When creating {insert,extract}value instructions from a BitcodeReader, we
weren't verifying the fields were valid.

Bugs found with afl-fuzz

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7325

llvm-svn: 229345
2015-02-16 00:03:11 +00:00
Aaron Ballman f9a1897c72 Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
2015-02-15 22:54:22 +00:00
Richard Smith 7b408025fd Clean up some inappropriate choices of type in the bitcode reader. None of
these are expected to fix any 64->32 bit real truncation issues.

llvm-svn: 229153
2015-02-13 21:05:11 +00:00
Duncan P. N. Exon Smith 1c93116489 AsmWriter/Bitcode: MDImportedEntity
llvm-svn: 229025
2015-02-13 01:46:02 +00:00
Duncan P. N. Exon Smith d45ce96c38 AsmWriter/Bitcode: MDObjCProperty
llvm-svn: 229024
2015-02-13 01:43:22 +00:00
Duncan P. N. Exon Smith 0c5c0124ac AsmWriter/Bitcode: MDExpression
llvm-svn: 229023
2015-02-13 01:42:09 +00:00
Duncan P. N. Exon Smith 72fe2d0b79 AsmWriter/Bitcode: MDLocalVariable
llvm-svn: 229022
2015-02-13 01:39:44 +00:00
Duncan P. N. Exon Smith c8f810a017 AsmWriter/Bitcode: MDGlobalVariable
llvm-svn: 229020
2015-02-13 01:35:40 +00:00
Duncan P. N. Exon Smith 2847f3805e AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter
llvm-svn: 229019
2015-02-13 01:34:32 +00:00
Duncan P. N. Exon Smith e146000565 AsmWriter/Bitcode: MDNamespace
llvm-svn: 229018
2015-02-13 01:32:09 +00:00
Duncan P. N. Exon Smith 06a0702e40 AsmWriter/Bitcode: MDLexicalBlockFile
llvm-svn: 229017
2015-02-13 01:30:42 +00:00
Duncan P. N. Exon Smith a96d409997 AsmWriter/Bitcode: MDLexicalBlock
llvm-svn: 229016
2015-02-13 01:29:28 +00:00
Duncan P. N. Exon Smith 19fc5ed7db AsmWriter/Bitcode: MDSubprogram
llvm-svn: 229014
2015-02-13 01:26:47 +00:00
Duncan P. N. Exon Smith c1f1acc751 AsmWriter/Bitcode: MDCompileUnit
llvm-svn: 229013
2015-02-13 01:25:10 +00:00
Duncan P. N. Exon Smith 54e2bc6c9b AsmWriter/Bitcode: MDSubroutineType
llvm-svn: 229011
2015-02-13 01:22:59 +00:00
Duncan P. N. Exon Smith 171d077ae4 AsmWriter/Bitcode: MDDerivedType and MDCompositeType
llvm-svn: 229009
2015-02-13 01:20:38 +00:00
Duncan P. N. Exon Smith f14b9c7cc1 AsmWriter/Bitcode: MDFile
llvm-svn: 229007
2015-02-13 01:19:14 +00:00
Duncan P. N. Exon Smith 09e03f38d6 AsmWriter/Bitcode: MDBasicType
llvm-svn: 229005
2015-02-13 01:14:58 +00:00
Duncan P. N. Exon Smith 8775476419 AsmWriter/Bitcode: MDEnumerator
llvm-svn: 229004
2015-02-13 01:14:11 +00:00
Duncan P. N. Exon Smith c7363f1147 AsmWriter/Bitcode: MDSubrange
llvm-svn: 229003
2015-02-13 01:10:38 +00:00
Zachary Turner 3bd47cee78 Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.
This allows IDEs to recognize the entire set of header files for
each of the core LLVM projects.

Differential Revision: http://reviews.llvm.org/D7526
Reviewed By: Chris Bieneman

llvm-svn: 228798
2015-02-11 03:28:02 +00:00
Peter Collingbourne 69ba0167b3 Misc documentation/comment fixes.
llvm-svn: 228093
2015-02-04 00:42:45 +00:00
Duncan P. N. Exon Smith 4e4aa70535 IR: Assembly and bitcode for GenericDebugNode
llvm-svn: 228041
2015-02-03 21:54:14 +00:00
Rafael Espindola dcfd6ed183 Propagate a better error message to the C api.
llvm-svn: 227934
2015-02-03 01:53:03 +00:00
Rafael Espindola 3ee23a9ec8 Use a non-fatal diag handler in the C API. FIxes PR22368.
llvm-svn: 227903
2015-02-03 00:49:57 +00:00
Duncan P. N. Exon Smith d9901ff586 IR: Split out DebugInfoMetadata.h, NFC
Move debug-info-centred `Metadata` subclasses into their own
header/source file.  A couple of private template functions are needed
from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them
to `lib/IR/MetadataImpl.h`.

llvm-svn: 227835
2015-02-02 18:53:21 +00:00
Filipe Cabecinhas fcd044b692 Check bit widths before trying to get a type.
Added a test case for it.
Also added run lines for the test case in r227566.

Bugs found with afl-fuzz

llvm-svn: 227589
2015-01-30 18:13:50 +00:00
Filipe Cabecinhas d0858e1037 [bitcode reader] Fix an assert on invalid type tables
Bug found with afl-fuzz

llvm-svn: 227566
2015-01-30 10:57:58 +00:00