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 t

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.

llvm-svn: 215804

show more ...

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
worke

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.

llvm-svn: 214899

show more ...

UseListOrder: Fix blockaddress use-list order

`parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as
a helper. Since `parseBitcodeFile()` isn't actually lazy -- it calls
`Material

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.

llvm-svn: 214581

show more ...

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 us

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.

llvm-svn: 214570

show more ...

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

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).

llvm-svn: 214559

show more ...

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.

llvm-svn: 214218

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 fi

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.

llvm-svn: 214209

show more ...

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
exper

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.

llvm-svn: 214125

show more ...

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

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).

llvm-svn: 213385

show more ...

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
Alig

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.

llvm-svn: 213352

show more ...

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
do

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

llvm-svn: 213118

show more ...

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).

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).

llvm-svn: 212357

show more ...

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

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.

llvm-svn: 212356

show more ...

Convert a few std::strings to StringRef.

llvm-svn: 212342

Convert these functions to use ErrorOr.

llvm-svn: 212341

Remove unused old-style error handling.

If needed, an ErrorOr should be used.

llvm-svn: 212340

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 o

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

llvm-svn: 211920

show more ...

IRReader: don't mark MemoryBuffers const

llvm-svn: 211883

Propagate const-correctness into parseBitcodeFile()

llvm-svn: 211864

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.

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.

llvm-svn: 211710

show more ...

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 t

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.

llvm-svn: 211542

show more ...

Revert a C API difference that I incorrectly introduced.

LLVMGetBitcodeModuleInContext should not take ownership on error. I will
try to localize this odd api requirement, but this should get the bo

Revert a C API difference that I incorrectly introduced.

LLVMGetBitcodeModuleInContext should not take ownership on error. I will
try to localize this odd api requirement, but this should get the bots green.

llvm-svn: 211213

show more ...

Remove BitcodeReader::setBufferOwned.

We do have use cases for the bitcode reader owning the buffer or not, but we
always know which one we have when we construct it.

It might be possible to simpli

Remove BitcodeReader::setBufferOwned.

We do have use cases for the bitcode reader owning the buffer or not, but we
always know which one we have when we construct it.

It might be possible to simplify this further, but this is a step in the
right direction.

llvm-svn: 211205

show more ...

IR: add "cmpxchg weak" variant to support permitted failure.

This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to

IR: add "cmpxchg weak" variant to support permitted failure.

This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.

As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.

At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.

By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.

Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.

Summary for out of tree users:
------------------------------

+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.

llvm-svn: 210903

show more ...

Remove 'using std::errro_code' from lib.

llvm-svn: 210871