Commit Graph

806 Commits

Author SHA1 Message Date
Rafael Espindola
8b8e2b2f81 clang-format two code snippets to make the next patch easy to read.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220484 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-23 15:20:05 +00:00
Duncan P. N. Exon Smith
cb3866e72e IR: Reorder metadata bitcode serialization, NFC
Enumerate `MDNode`'s operands *before* the node itself, so that the
reader requires less RAUW.  Although this will cause different code
paths to be hit in the reader, this should effectively be no
functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220340 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-21 22:27:47 +00:00
Duncan P. N. Exon Smith
9fa8641288 IR: Remove dead code in metadata bitcode writing, NFC
No one cares how many uses each metadata value has, so don't bother
counting.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220337 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-21 22:13:34 +00:00
Sanjay Patel
ddcfe81459 correct const-ness with auto and dyn_cast
1. Use const with autos.
2. Don't bother with explicit const in cast ops because they do it automagically.

Thanks, David B. / Aaron B. / Reid K.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219817 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-15 17:45:13 +00:00
Sanjay Patel
5af49c83c3 Use 'auto' for easier reading; no functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219804 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-15 16:21:37 +00:00
Peter Collingbourne
75202eb0c6 Introduce LLVMWriteBitcodeToMemoryBuffer C API function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219643 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-14 00:30:59 +00:00
Petar Jovanovic
fd42335e83 Do not destroy external linkage when deleting function body
The function deleteBody() converts the linkage to external and thus destroys
original linkage type value. Lack of correct linkage type causes wrong
relocations to be emitted later.
Calling dropAllReferences() instead of deleteBody() will fix the issue.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218302 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-23 12:54:19 +00:00
Chris Bieneman
4ea1a1185a Eliminating static destructor for the BitCodeErrorCategory by converting to a ManagedStatic.
Summary: This is part of the overall goal of removing static initializers from LLVM.

Reviewers: chandlerc

Reviewed By: chandlerc

Subscribers: chandlerc, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218149 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 20:29:02 +00:00
Benjamin Kramer
57a73c27b1 Use IntrusiveRefCntPtr to manage the lifetime of BitCodeAbbrevs.
This doesn't change the interface or gives additional safety but removes
a ton of retain/release boilerplate.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217778 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-15 15:44:14 +00:00
Rafael Espindola
6d66a1cd2f Pass a && to getLazyBitcodeModule.
This forces callers to use std::move when calling it. It is somewhat odd to have
code with std::move that doesn't always move, but it is also odd to have code
without std::move that sometimes moves.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-03 17:31:46 +00:00
Rafael Espindola
aa9db69bb5 Fix a double free in llvm::getBitcodeTargetTriple.
Unfortunately this is only used by ld64, so no testcase, but should fix the darwin LTO bootstrap.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216618 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-27 21:11:13 +00:00
Rafael Espindola
fb1af0a48a Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.
By taking a reference we can do the ownership transfer in one place instead of
expecting every caller to do it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216492 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 22:00:09 +00:00
Rafael Espindola
2292996e1a Pass a MemoryBufferRef when we can avoid taking ownership.
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216488 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 21:49:01 +00:00
Rafael Espindola
8c96862847 Modernize raw_fd_ostream's constructor a bit.
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.

A create static method would be even better, but this patch is already a bit too
big.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216393 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-25 18:16:47 +00:00
Duncan P. N. Exon Smith
1d8c9d95bf BitcodeReader: Only create one basic block for each blockaddress
Block address forward-references are implemented by creating a
`BasicBlock` ahead of time that gets inserted in the `Function` when
it's eventually encountered.

However, if the same blockaddress was used in two separate functions
that were parsed *before* the referenced function (and the blockaddress
was never used at global scope), two separate basic blocks would get
created, one of which would be forgotten creating invalid IR.

This commit changes the forward-reference logic to create only one basic
block (and always return the same blockaddress).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215805 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-16 01:54:37 +00:00
Duncan P. N. Exon Smith
1e97329f27 UseListOrder: Correctly count the number of uses
This is an off-by-one bug I found by inspection, which would only
trigger if the bitcode writer sees more uses of a `Value` than the
reader.  Since this is only relevant when an instruction gets upgraded
somehow, there unfortunately isn't a reasonable way to add test
coverage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215804 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-16 01:54:34 +00:00
Benjamin Kramer
00e08fcaa0 Canonicalize header guards into a common format.
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)

Changes made by clang-tidy with minor tweaks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215558 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-13 16:26:38 +00:00
Duncan P. N. Exon Smith
7f2cd21ddd BitcodeReader: Fix non-determinism in use-list order
`BasicBlockFwdRefs` (and `BlockAddrFwdRefs` before it) was being emptied
in a non-deterministic order.  When predicting use-list order I've
worked around this another way, but even when parsing lazily (and we
can't recreate use-list order) use-lists should be deterministic.

Make them so by using a side-queue of functions with forward-referenced
blocks that gets visited in order.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214899 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 17:49:48 +00:00
Duncan P. N. Exon Smith
1526278443 UseListOrder: Fix blockaddress use-list order
`parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as
a helper.  Since `parseBitcodeFile()` isn't actually lazy -- it calls
`MaterializeAllPermanently()` -- bypass the unnecessary call to
`materializeForwardReferencedFunctions()` by extracting out a common
helper function.  This removes the last of the use-list churn caused by
blockaddresses.

This highlights that we can't reproduce use-list order of globals and
constants when parsing lazily -- but that's necessarily out of scope.
When we're parsing lazily, we never have all the functions in memory, so
the use-lists of globals (and constants that reference globals) are
always incomplete.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214581 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 22:27:19 +00:00
Duncan P. N. Exon Smith
147851ef9d BitcodeReader: Change mechanics of BlockAddress forward references, NFC
Now that we can reliably handle forward references to `BlockAddress`
(r214563), change the mechanics to simplify predicting use-list order.

Previously, we created dummy `GlobalVariable`s to represent block
addresses.  After every function was materialized, we'd go through any
forward references to its blocks and RAUW them with a proper
`BlockAddress` constant.  This causes some (potentially a lot of)
unnecessary use-list churn, since any constant expression that it's a
part of will need to be rematerialized as well.

Instead, pre-construct a `BasicBlock` immediately -- without attaching
it to its (empty) `Function` -- and use that to construct a
`BlockAddress`.  This constant will not have to be regenerated.  When
the function body is parsed, hook this pre-constructed basic block up
in the right place using `BasicBlock::insertInto()`.

Both before and after this change, the IR is temporarily in an invalid
state that gets resolved when `materializeForwardReferencedFunctions()`
gets called.

This is a prep commit that's part of PR5680, but the only functionality
change is the reduction of churn in the constant pool.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214570 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 21:51:52 +00:00
Duncan P. N. Exon Smith
cf8b959e8d BitcodeReader: Fix some BlockAddress forward reference corner cases
`BlockAddress`es are interesting in that they can reference basic blocks
from *outside* the block's function.  Since basic blocks are not global
values, this presents particular challenges for lazy parsing.

One corner case was found in PR11677 and fixed in r147425.  In that
case, a global variable references a block address.  It's necessary to
load the relevant function to resolve the forward reference before doing
anything with the module.

By inspection, I found (and have fixed here) two other cases:

  - An instruction from one function references a block address from
    another function, and only the first function is lazily loaded.

    I fixed this the same way as PR11677: by eagerly loading the
    referenced function.

  - A function whose block address is taken is dematerialized, leaving
    invalid references to it.

    I fixed this by refusing to dematerialize functions whose block
    addresses are taken (if you have to load it, you can't unload it).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214559 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 21:11:34 +00:00
Duncan P. N. Exon Smith
9d65d3717c UseListOrder: Handle self-users
Correctly sort self-users (such as PHI nodes).  I added a targeted test
in `test/Bitcode/use-list-order.ll` and the final missing RUN line to
tests in `test/Assembly`.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214417 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 18:33:12 +00:00
Duncan P. N. Exon Smith
e5ae09b08f UseListOrder: Don't give constant IDs to GlobalValues
Since initializers of GlobalValues are being assigned IDs before
GlobalValues themselves, explicitly exclude GlobalValues from the
constant pool.  Added targeted test in `test/Bitcode/use-list-order.ll`
and added two more RUN lines in `test/Assembly`.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214368 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 00:13:28 +00:00
Duncan P. N. Exon Smith
43b54db2a4 UseListOrder: Visit global values
When predicting use-list order, we visit functions in reverse order
followed by `GlobalValue`s and write out use-lists at the first
opportunity.  In the reader, this will translate to *after* the last use
has been added.

For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.

There are two remaining failures in `test/Bitcode`:

  - blockaddress.ll: I haven't thought through how to model the way
    block addresses change the order of use-lists (or how to work around
    it).

  - metadata-2.ll: There's an old-style `@llvm.used` global array here
    that I suspect the .ll parser isn't upgrading properly.  When it
    round-trips through bitcode, the .bc reader *does* upgrade it, so
    the extra variable (`i8* null`) has an extra use, and the shuffle
    vector doesn't match.

    I think the fix is to upgrade old-style global arrays (or reject
    them?) in the .ll parser.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 17:51:09 +00:00
Duncan P. N. Exon Smith
cd29d80204 Reapply "UseListOrder: Order GlobalValue uses after initializers"
This reverts commit r214249, reapplying r214242 and r214243, now that
r214270 has fixed the UB.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214271 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 01:22:16 +00:00
Duncan P. N. Exon Smith
c128f3b34c UseListOrder: Fix undefined behaviour
This commit fixes undefined behaviour that caused the revert in r214249.

The problem was two unsequenced operations on a `DenseMap<>`, giving
different behaviour in GCC and Clang.  This:

    DenseMap<T*, unsigned> DM;
    for (auto &X : ...)
      DM[&X] = DM.size() + 1;

should have been:

    DenseMap<T*, unsigned> DM;
    for (auto &X : ...) {
      unsigned Size = DM.size();
      DM[&X] = Size + 1;
    }

Until r214242, this difference between compilers didn't matter.  In
r214242, `OrderMap::LastGlobalValueID` was introduced and compared
against IDs, which in GCC were off-by-one my expectations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214270 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 01:20:26 +00:00
Duncan P. N. Exon Smith
70fec68744 Revert "UseListOrder: Order GlobalValue uses after initializers"
This reverts commits r214242 and r214243 while I investigate buildbot
failures [1][2][3].  I can't reproduce these failures locally, so if
anyone can see what I've done wrong, I'd appreciate a note.

[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9840
[2]: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/14981
[3]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/15191

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214249 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 23:31:11 +00:00
Duncan P. N. Exon Smith
9b9c19509f UseListOrder: Order GlobalValue uses after initializers
To avoid unnecessary forward references, the reader doesn't process
initializers of `GlobalValue`s until after the constant pool has been
processed, and then in reverse order.  Model this when predicting
use-list order.  This gets two more Bitcode tests passing with
`llvm-uselistorder`.

Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214242 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 23:06:14 +00:00
Duncan P. N. Exon Smith
abf3c77acb UseListOrder: Create a struct around OrderMap, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214241 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 23:03:40 +00:00
Rafael Espindola
63252a0aa3 Have a single enum for "not a bitcode" error.
This is more convenient for callers. No functionality change, this will
be used in a next patch to the gold plugin.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 21:01:24 +00:00
Rafael Espindola
75a9d37187 Move the bitcode error enum to the include directory.
This will let users in other libraries know which error occurred. In particular,
it will be possible to check if the parsing failed or if the file is not
bitcode.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214209 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 20:22:46 +00:00
Duncan P. N. Exon Smith
34fa69757f IR: Create the use-list order shuffle vector in-place
Per David Blaikie's review of r214135, this is a more natural way to
initialize.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214184 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 16:58:18 +00:00
Duncan P. N. Exon Smith
994af148ca Bitcode: Correctly compare a Use against itself
Fix the sort of expected order in the reader to correctly return `false`
when comparing a `Use` against itself.

This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm
adding a `RUN` line using `llvm-uselistorder` for every test in
`test/Bitcode` that passes.

A few tests still fail, so I'll investigate those next.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214157 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 01:13:56 +00:00
Duncan P. N. Exon Smith
f575ec435e IR: Optimize size of use-list order shuffle vectors
Since we're storing lots of these, save two-pointers per vector with a
custom type rather than using the relatively heavy `SmallVector`.

Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214135 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 22:41:50 +00:00
Duncan P. N. Exon Smith
bd24fe8c7e Bitcode: Serialize (and recover) use-list order
Predict and serialize use-list order in bitcode.  This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.

  - Builds a full value-table up front in the writer, sets up a list of
    use-list orders to write out, and discards the table.  This is a
    simpler first step than determining the order from the various
    overlapping IDs of values on-the-fly.

  - The shuffles stored in the use-list order list have an unnecessarily
    large memory footprint.

  - `blockaddress` expressions cause functions to be materialized
    out-of-order.  For now I've ignored this problem, so use-list orders
    will be wrong for constants used by functions that have block
    addresses taken.  There are a couple of ways to fix this, but I
    don't have a concrete plan yet.

  - When materializing functions lazily, the use-lists for constants
    will not be correct.  This use case is out of scope: what should the
    use-list order be, if it's incomplete?

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214125 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 21:19:41 +00:00
Duncan P. N. Exon Smith
17cb4cb5a3 Bitcode: Don't optimize constants when preserving use-list order
`ValueEnumerator::OptimizeConstants()` creates forward references within
the constant pools, which makes predicting constants' use-list order
difficult.  For now, just disable the optimization.

This can be re-enabled in the future in one of two ways:

  - Enable a limited version of this optimization that doesn't create
    forward references.  One idea is to categorize constants by their
    "height" and make that the top-level sort.

  - Enable it entirely.  This requires predicting how may times each
    constant will be recreated as its operands' and operands' operands'
    (etc.) forward references get resolved.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213953 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:13:16 +00:00
Duncan P. N. Exon Smith
7bf73bd378 IPO: Add use-list-order verifier
Add a -verify-use-list-order pass, which shuffles use-list order, writes
to bitcode, reads back, and verifies that the (shuffled) order matches.

  - The utility functions live in lib/IR/UseListOrder.cpp.

  - Moved (and renamed) the command-line option to enable writing
    use-lists, so that this pass can return early if the use-list orders
    aren't being serialized.

It's not clear that this pass is the right direction long-term (perhaps
a separate tool instead?), but short-term it's a great way to test the
use-list order prototype.  I've added an XFAIL-ed testcase that I'm
hoping to get working pretty quickly.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213945 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 14:49:26 +00:00
Hal Finkel
11af4b49b2 Add a dereferenceable attribute
This attribute indicates that the parameter or return pointer is
dereferenceable. Practically speaking, loads from such a pointer within the
associated byte range are safe to speculatively execute. Such pointer
parameters are common in source languages (C++ references, for example).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213385 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 15:51:28 +00:00
Hal Finkel
d0261683e8 Rename AlignAttribute to IntAttribute
Currently the only kind of integer IR attributes that we have are alignment
attributes, and so the attribute kind that takes an integer parameter is called
AlignAttr, but that will change (we'll soon be adding a dereferenceable
attribute that also takes an integer value). Accordingly, rename AlignAttribute
to IntAttribute (class names, enums, etc.).

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213352 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 06:51:55 +00:00
Reid Kleckner
55a421f98d Roundtrip the inalloca bit on allocas through bitcode
This was an oversight in the original support.  As it is, I stuffed this
bit into the alignment.  The alignment is stored in log2 form, so it
doesn't need more than 5 bits, given that Value::MaximumAlignment is 1
<< 29.

Reviewers: nicholas

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213118 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-16 01:34:27 +00:00
Rafael Espindola
483d89bcd4 Fix a bug in the conversion to ErrorOr.
The regular end of the bitcode parsing is in the  BitstreamEntry::EndBlock
case.

Should fix the LTO bootstrap on OS X (this function is only used by ld64).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 20:05:56 +00:00
Rafael Espindola
c77a7749ff Revert "Convert a few std::strings to StringRef."
This reverts commit r212342.

We can get a StringRef into the current Record, but not one in the bitcode
itself since the string is compressed in it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212356 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 20:02:42 +00:00
Rafael Espindola
9f72a18a50 Convert a few std::strings to StringRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212342 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 14:12:46 +00:00
Rafael Espindola
2d1f275c99 Convert these functions to use ErrorOr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212341 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 13:52:01 +00:00
Rafael Espindola
82a599a0a4 Remove unused old-style error handling.
If needed, an ErrorOr should be used.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212340 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 13:30:13 +00:00
David Majnemer
c8a1169c93 IR: Add COMDATs to the IR
This new IR facility allows us to represent the object-file semantic of
a COMDAT group.

COMDATs allow us to tie together sections and make the inclusion of one
dependent on another. This is required to implement features like MS
ABI VFTables and optimizing away certain kinds of initialization in C++.

This functionality is only representable in COFF and ELF, Mach-O has no
similar mechanism.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211920 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 18:19:56 +00:00
Alp Toker
9b0be7b61a IRReader: don't mark MemoryBuffers const
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211883 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 09:19:14 +00:00
Alp Toker
9fc1a6ffb7 Propagate const-correctness into parseBitcodeFile()
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211864 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 04:48:32 +00:00
Eli Bendersky
bb167336b3 Rename loop unrolling and loop vectorizer metadata to have a common prefix.
[LLVM part]

These patches rename the loop unrolling and loop vectorizer metadata
such that they have a common 'llvm.loop.' prefix.  Metadata name
changes:

llvm.vectorizer.* => llvm.loop.vectorizer.*
llvm.loopunroll.* => llvm.loop.unroll.*

This was a suggestion from an earlier review
(http://reviews.llvm.org/D4090) which added the loop unrolling
metadata. 

Patch by Mark Heffernan.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211710 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 15:41:00 +00:00
Rafael Espindola
1f659329b6 Make ObjectFile and BitcodeReader always own the MemoryBuffer.
This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.

Overall this looks like a more efficient and less brittle api.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211542 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-23 21:53:12 +00:00