[llvm] Use true/false instead of 1/0 (NFC)

Identified with modernize-use-bool-literals.

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

Try harder to fix bugpoint with GCC5

Make bugpoint work with gcc5 again.

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

[Bugpoint] fix another use-after-move. NFC

Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
7".

These statements are order independent, short of the use-after-move.

[Bugpoint] fix another use-after-move. NFC

Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
7".

These statements are order independent, short of the use-after-move.

Reviewers: echristo, srhines, RKSimon

Reviewed By: RKSimon

Subscribers: dblaikie, llvm-commits

Tags: #llvm

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

llvm-svn: 362267

show more ...

[Bugpoint] fix use-after-move. NFC

Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
6".

Note that author also states:
"Note that the loop doesn't actually execute a

[Bugpoint] fix use-after-move. NFC

Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
6".

Note that author also states:
"Note that the loop doesn't actually execute at all."

This is not true, but the author can be forgiven; there's two distinct
variables with very similar identifiers:

MiscompiledFunctions
MisCompFunctions

Reviewers: echristo, srhines, RKSimon

Reviewed By: RKSimon

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 361279

show more ...

[opaque pointer types] Pass value type to LoadInst creation.

This cleans up all LoadInst creation in LLVM to explicitly pass the
value type rather than deriving it from the pointer's element-type.

[opaque pointer types] Pass value type to LoadInst creation.

This cleans up all LoadInst creation in LLVM to explicitly pass the
value type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352911

show more ...

[opaque pointer types] Pass function types to CallInst creation.

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-ty

[opaque pointer types] Pass function types to CallInst creation.

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352909

show more ...

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The Func

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352827

show more ...

Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."

This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791).

Seems to run into compilation failures with GC

Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."

This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791).

Seems to run into compilation failures with GCC (but not clang, where
I tested it). Reverting while I investigate.

llvm-svn: 352800

show more ...

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue pas

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352791

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

[bugpoint] Fix crash when testing for miscompilation.

Method BugDriver::performFinalCleanups(...) would delete Module object
it worked on, which was also deleted by its caller
(e.g. TestCodeGenerato

[bugpoint] Fix crash when testing for miscompilation.

Method BugDriver::performFinalCleanups(...) would delete Module object
it worked on, which was also deleted by its caller
(e.g. TestCodeGenerator(...)). Changed the code to avoid double delete
and make Module ownership slightly clearer.

Patch by Andrzej Janik.

llvm-svn: 330763

show more ...

Change the BugDriver to store the current module with std::unique_ptr.

While there, change a bunch of helper functions to take references to
avoid adding calls to get().

This should conclude the bu

Change the BugDriver to store the current module with std::unique_ptr.

While there, change a bunch of helper functions to take references to
avoid adding calls to get().

This should conclude the bugpoint yak shaving.

llvm-svn: 325177

show more ...

Use std::uniue_ptr. NFC.

llvm-svn: 325176

Use std::unique_ptr. NFC.

llvm-svn: 325174

Use std::unique_ptr. NFC.

llvm-svn: 325173

Use std::unique_ptr. NFC.

llvm-svn: 325164

Pass a module reference to CloneModule.

It can never be null and most callers were already using references or
std::unique_ptr.

llvm-svn: 325160

Module::getOrInsertFunction is using C-style vararg instead of variadic templates.

From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not ty

Module::getOrInsertFunction is using C-style vararg instead of variadic templates.

From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments.
The variadic template is an obvious solution to both issues.

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

llvm-svn: 299949

show more ...

[Bugpoint] Use `unique_ptr` correctly.

Moving Modules into `testMergedProgram` is incorrect (and causes segmentation
faults) since all callers expect to retain ownership. This is evidenced by the
la

[Bugpoint] Use `unique_ptr` correctly.

Moving Modules into `testMergedProgram` is incorrect (and causes segmentation
faults) since all callers expect to retain ownership. This is evidenced by the
later calls to `unique_ptr<Module>::get` in the same function.

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

llvm-svn: 299596

show more ...

Retire bugpoint's -R. hack.

It got disconnected during the cmake conversion. For Miscompilation.cpp,
it was purely advisory for the user and the ToolRunner.cpp version was
trying to compensate for l

Retire bugpoint's -R. hack.

It got disconnected during the cmake conversion. For Miscompilation.cpp,
it was purely advisory for the user and the ToolRunner.cpp version was
trying to compensate for libs and bins in the same directory, which
hasn't been the case for a very long time.

llvm-svn: 283022

show more ...

bugpoint: Return Errors instead of passing around strings

This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places

bugpoint: Return Errors instead of passing around strings

This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.

This is more or less NFC, but does move around where a couple of error
messages are printed out.

llvm-svn: 280720

show more ...