Modernize the error handling of the Materialize function.

llvm-svn: 220600

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 cau

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

llvm-svn: 218302

show more ...

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
with

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.

llvm-svn: 217049

show more ...

Return a std::unique_ptr when creating a new MemoryBuffer.

llvm-svn: 216583

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.

llvm-svn: 216492

Modernize the .ll parsing interface.

* Use StringRef instead of std::string&
* Return a std::unique_ptr<Module> instead of taking an optional module to write
to (was not really used).
* Use curren

Modernize the .ll parsing interface.

* Use StringRef instead of std::string&
* Return a std::unique_ptr<Module> instead of taking an optional module to write
to (was not really used).
* Use current comment style.
* Use current naming convention.

llvm-svn: 215989

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

Rewrite BitReaderTest, NFC

Rewrite the single unit test in `BitReaderTest` so that it's easier to
add more tests.

- Parse from an assembly string rather than using API.
- Use more helper functi

Rewrite BitReaderTest, NFC

Rewrite the single unit test in `BitReaderTest` so that it's easier to
add more tests.

- Parse from an assembly string rather than using API.
- Use more helper functions.
- Use a separate context for the module on the other side.

Aside from relying on the assembly parser, there's no functionality
change intended.

llvm-svn: 214556

show more ...

verify-di: Implement DebugInfoVerifier

Implement DebugInfoVerifier, which steals verification relying on
DebugInfoFinder from Verifier.

- Adds LegacyDebugInfoVerifierPassPass, a ModulePass which

verify-di: Implement DebugInfoVerifier

Implement DebugInfoVerifier, which steals verification relying on
DebugInfoFinder from Verifier.

- Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps
DebugInfoVerifier. Uses -verify-di command-line flag.

- Change verifyModule() to invoke DebugInfoVerifier as well as
Verifier.

- Add a call to createDebugInfoVerifierPass() wherever there was a
call to createVerifierPass().

This implementation as a module pass should sidestep efficiency issues,
allowing us to turn debug info verification back on.

<rdar://problem/15500563>

llvm-svn: 206300

show more ...

Replace OwningPtr<T> with std::unique_ptr<T>.

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which ha

Replace OwningPtr<T> with std::unique_ptr<T>.

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

show more ...

Update getLazyBitcodeModule to use ErrorOr for error handling.

llvm-svn: 199125

[cleanup] Move the Dominators.h and Verifier.h headers into the IR
directory. These passes are already defined in the IR library, and it
doesn't make any sense to have the headers in Analysis.

Long

[cleanup] Move the Dominators.h and Verifier.h headers into the IR
directory. These passes are already defined in the IR library, and it
doesn't make any sense to have the headers in Analysis.

Long term, I think there is going to be a much better way to divide
these matters. The dominators code should be fully separated into the
abstract graph algorithm and have that put in Support where it becomes
obvious that evn Clang's CFGBlock's can use it. Then the verifier can
manually construct dominance information from the Support-driven
interface while the Analysis library can provide a pass which both
caches, reconstructs, and supports a nice update API.

But those are very long term, and so I don't want to leave the really
confusing structure until that day arrives.

llvm-svn: 199082

show more ...

llvm/unittests: Use OwningPtr to fix --vg-leak.

llvm-svn: 173240

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

show more ...

Bitcode: Don't expose WriteBitcodeToStream to clients.

llvm-svn: 151747

Undo the hack in r147427 and move this unittest to a better home. This
is testing the bitcode reader's functionality, not VMCore's. Add the
what is a hope sufficient build system mojo to build and ru

Undo the hack in r147427 and move this unittest to a better home. This
is testing the bitcode reader's functionality, not VMCore's. Add the
what is a hope sufficient build system mojo to build and run a new
unittest.

Also clean up some of the test's naming. The goal for the file should be
to unittest the Bitcode Reader, and this is just one particular test
among potentially many in the future. Also, reverse my position and
relegate the PR# to a comment, but stash the comment on the same line as
the test name so it doesn't get lost. This makes the code more
self-documenting hopefully w/o losing track of the PR number.

llvm-svn: 147431

show more ...