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

Remove all uses of 'using std::error_code' from headers.

llvm-svn: 210866

Don't import error_category into the llvm namespace.

llvm-svn: 210733

Mark a few functions noexcept.

This reduces the difference between std::error_code and llvm::error_code.

llvm-svn: 210591

Allow aliases to be unnamed_addr.

Alias with unnamed_addr were in a strange state. It is stored in GlobalValue,
the language reference talks about "unnamed_addr aliases" but the verifier
was rejecti

Allow aliases to be unnamed_addr.

Alias with unnamed_addr were in a strange state. It is stored in GlobalValue,
the language reference talks about "unnamed_addr aliases" but the verifier
was rejecting them.

It seems natural to allow unnamed_addr in aliases:

* It is a property of how it is accessed, not of the data itself.
* It is perfectly possible to write code that depends on the address
of an alias.

This patch then makes unname_addr legal for aliases. One side effect is that
the syntax changes for a corner case: In globals, unnamed_addr is now printed
before the address space.

llvm-svn: 210302

show more ...