[strictfp] Replace dangling strictfp attrs with nobuiltin

In preparation for a patch that will enforce new rules for the usage of
the strictfp attribute, this patch introduces auto-upgrade behavior

[strictfp] Replace dangling strictfp attrs with nobuiltin

In preparation for a patch that will enforce new rules for the usage of
the strictfp attribute, this patch introduces auto-upgrade behavior that
will replace the strictfp attribute on callsites with nobuiltin if the
enclosing function declaration doesn't also have the strictfp attribute.

This auto-upgrade isn't being performed on .ll files because that would
prevent us from writing a test for the forthcoming verifier behavior.

Differential Revision: https://reviews.llvm.org/D70096

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Pass a reference to a module to the bitcode writer.

This simplifies most callers as they are already using references or
std::unique_ptr.

llvm-svn: 325155

Remove redundant includes from unittests.

llvm-svn: 320630

Bitcode: Change module reader functions to return an llvm::Expected.

Differential Revision: https://reviews.llvm.org/D26562

llvm-svn: 286752

Split Bitcode/ReaderWriter.h into separate reader and writer headers

Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and Bi

Split Bitcode/ReaderWriter.h into separate reader and writer headers

Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and BitcodeWriter.h.

This is to address Chandler's concern about sharing the same API header
between multiple libraries (BitReader and BitWriter). That concern is
why we create a single bitcode library in our downstream build of clang,
which led to r286297 being reverted as it added a dependency that
created a cycle only when there is a single bitcode library (not two as
in upstream).

Reviewers: mehdi_amini

Subscribers: dlj, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D26502

llvm-svn: 286566

show more ...

Bitcode: Change the materializer interface to return llvm::Error.

Differential Revision: https://reviews.llvm.org/D26439

llvm-svn: 286382

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as th

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.

The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.

Differential Revision: https://reviews.llvm.org/D26384

llvm-svn: 286214

show more ...

Bitcode: Change reader interface to take memory buffers.

As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html

This change also fixes an API oddity where Bitstr

Bitcode: Change reader interface to take memory buffers.

As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html

This change also fixes an API oddity where BitstreamCursor::Read() would
return zero for the first read past the end of the bitstream, but would
report_fatal_error for subsequent reads. Now we always report_fatal_error
for all reads past the end. Updated clients to check for the end of the
bitstream before reading from it.

I also needed to add padding to the invalid bitcode tests in
test/Bitcode/. This is because the streaming interface was not checking that
the file size is a multiple of 4.

Differential Revision: https://reviews.llvm.org/D26219

llvm-svn: 285773

show more ...

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
dest

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 <[email protected]>
llvm-svn: 266379

show more ...

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

Fix memory leak in unit test of Bitcode/BitReaderTest.cpp

Fixes obvious memory leak in test
TestForEofAfterReadFailureOnDataStreamer. Also removes constexpr use
from same test.

Patch by Karl Schim

Fix memory leak in unit test of Bitcode/BitReaderTest.cpp

Fixes obvious memory leak in test
TestForEofAfterReadFailureOnDataStreamer. Also removes constexpr use
from same test.

Patch by Karl Schimpf.

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

llvm-svn: 243904

show more ...

Fix testing for end of stream in bitstream reader.

This fixes a bug found while working on the bitcode reader. In
particular, the method BitstreamReader::AtEndOfStream doesn't always
behave correctl

Fix testing for end of stream in bitstream reader.

This fixes a bug found while working on the bitcode reader. In
particular, the method BitstreamReader::AtEndOfStream doesn't always
behave correctly when processing a data streamer. The method
fillCurWord doesn't properly set CurWord/BitsInCurWord if the data
streamer was already at eof, but GetBytes had not yet set the
ObjectSize field of the streaming memory object.

This patch fixes this problem, and provides a test to show that
this problem has been fixed.

Patch by Karl Schimpf.

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

llvm-svn: 243890

show more ...

Try to fix the MSVC build.

llvm-svn: 239877

Handle forward referenced function when streaming bitcode.

Without this the included unit test would assert in

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

llvm

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

show more ...

Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.

llvm-svn: 239858

While in GlobalValue fix the function(s) that don't follow the
naming convention and update users.

llvm-svn: 237461

Add bitcode test to verify functions can be materialized out of order.

Summary:
Adds test to check that when getLazyBitcodeModule is called:
1) Functions are not materailzed by default.
2) Only the

Add bitcode test to verify functions can be materialized out of order.

Summary:
Adds test to check that when getLazyBitcodeModule is called:
1) Functions are not materailzed by default.
2) Only the requested function gets materialized (if no block addresses
are used).

Reviewers: jvoung, rafael

Reviewed By: rafael

Subscribers: llvm-commits

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

llvm-svn: 236611

show more ...

[cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the Inst

[cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974

show more ...

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