[llvm][unittests] Strip unneeded uses of raw_string_ostream::str() (NFC)

Avoid excess layer of indirection.

[FPEnv][BitcodeReader] Correct strictfp test.

Correct a strictfp test to follow the rules documented in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

This te

[FPEnv][BitcodeReader] Correct strictfp test.

Correct a strictfp test to follow the rules documented in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

This test needed the strictfp attribute added to a function definition.

Test changes verified with D146845.

show more ...

[llvm] Stop including llvm/ADT/MapVector.h (NFC)

Identified with clangd.

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque
pointers. This is a lossy conversion, i.e. when a function argument is a
pointer and unused, it’s impossible to reconstruct the original type
behind the pointer.

There are cases where the type information of pointers is needed. One is
reading DXIL, which is bitcode of old LLVM IR and makes a lot of use of
pointers in function signatures.
We’d like to keep using up-to-date llvm to read in and process DXIL, so
in the face of opaque pointers, we need some way to access the type
information of pointers from the read bitcode.

This patch allows extracting type information by supplying functions to
parseBitcodeFile that get called for each function signature or metadata
value. The function can access the type information via the reader’s
type IDs and the getTypeByID and getContainedTypeID functions.
The tests exemplarily shows how type info from pointers can be stored in
metadata for use after the BitcodeReader finished.

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

show more ...

Revert "[BitcodeReader] Allow reading pointer types from old IR"

This reverts commit b56df190b01335506ce30a4559d880da76d1a181.

The unit tests are implemented in a way that requires support for
writ

Revert "[BitcodeReader] Allow reading pointer types from old IR"

This reverts commit b56df190b01335506ce30a4559d880da76d1a181.

The unit tests are implemented in a way that requires support for
writing typed pointer bitcode, which is going away soon. Please
rewrite it in a way that not have requirement, e.g. by shipping
pre-compiled bitcode, as we do for integration tests.

show more ...

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque
pointers. This is a lossy conversion, i.e. when a function argument is a
pointer and unused, it’s impossible to reconstruct the original type
behind the pointer.

There are cases where the type information of pointers is needed. One is
reading DXIL, which is bitcode of old LLVM IR and makes a lot of use of
pointers in function signatures.
We’d like to keep using up-to-date llvm to read in and process DXIL, so
in the face of opaque pointers, we need some way to access the type
information of pointers from the read bitcode.

This patch allows extracting type information by supplying functions to
parseBitcodeFile that get called for each function signature or metadata
value. The function can access the type information via the reader’s
type IDs and the getTypeByID and getContainedTypeID functions.
The tests exemplarily shows how type info from pointers can be stored in
metadata for use after the BitcodeReader finished.

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

show more ...

[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 <mehdi.amini@apple.com>
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 ...