[NFC][Fuzzer] Refactor to avoid a false warning from gcc (#112944)

This is one of the many PRs to fix errors with LLVM_ENABLE_WERROR=on.
Built by GCC 11.

Refactor the code to avoid the false war

[NFC][Fuzzer] Refactor to avoid a false warning from gcc (#112944)

This is one of the many PRs to fix errors with LLVM_ENABLE_WERROR=on.
Built by GCC 11.

Refactor the code to avoid the false warning

llvm-project/llvm/tools/llvm-isel-fuzzer/llvm-isel-fuzzer.cpp
llvm-project/llvm/tools/llvm-isel-fuzzer/llvm-isel-fuzzer.cpp: In
function ‘int LLVMFuzzerInitialize(int*, char***)’:
llvm-project/llvm/tools/llvm-isel-fuzzer/llvm-isel-fuzzer.cpp:141:43:
error: ISO C++ forbids zero-size array ‘argv’ [-Werror=pedantic]
141 | ExitOnError ExitOnErr(std::string(*argv[0]) + ": error:");
|

show more ...

Introduce and use codegen::createTargetMachineForTriple()

This creates a TargetMachine with the default options (from the command
line flags). This allows us to share a bit more code between tools.

Introduce and use codegen::createTargetMachineForTriple()

This creates a TargetMachine with the default options (from the command
line flags). This allows us to share a bit more code between tools.

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

show more ...

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future chang

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.

This matches other nearby enums.

For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::

show more ...

[FuzzMutate] Module size heuristics

IRMutation::mutateModule() currently requires the bitcode size of the module.
To compute the bitcode size, one way is to write the module to a buffer using
Bitcod

[FuzzMutate] Module size heuristics

IRMutation::mutateModule() currently requires the bitcode size of the module.
To compute the bitcode size, one way is to write the module to a buffer using
BitcodeWriter and calculating the buffer size. This would be fine for a single
mutation, but infeasible for repeated mutations due to the large overhead. It
turns out that the only IR strategy weight calculation method that depends on
the current module size is InstDeleterStrategy, which deletes instructions more
frequently as the module size approaches a given max size. However, there is no
real need for the size to be in bytes of bitcode, so we can use a different
metric. One alternative is to let the size be the number of objects in the
Module, including instructions, basic blocks, globals, and aliases. Although
getting the number of instructions is still O(n), it should have significantly
less overhead than BitcodeWriter. This suggestion would cause a change to the
IRMutator API, since IRMutator::mutateModule() can calculate the Module size
itself.

Reviewed By: Peter

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

show more ...

[NFC] Consolidate llvm::CodeGenOpt::Level handling

Add free functions llvm::CodeGenOpt::{getLevel,getID,parseLevel} to
provide common implementations for functionality that has been
duplicated in ma

[NFC] Consolidate llvm::CodeGenOpt::Level handling

Add free functions llvm::CodeGenOpt::{getLevel,getID,parseLevel} to
provide common implementations for functionality that has been
duplicated in many places across the codebase.

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

show more ...

Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[Support] Change fatal_error_handler_t to take a const char* instead of std::string

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <

[Support] Change fatal_error_handler_t to take a const char* instead of std::string

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <string> header has a massive impact on compile time; its most commonly included via the ErrorHandling.h header, which has to be included in many key headers, impacting many source files that have no need for std::string.

As an initial step toward removing the <string> include from ErrorHandling.h, this patch proposes to update the fatal_error_handler_t handler to just take a raw const char* instead.

The next step will be to remove the report_fatal_error std::string variant, which will involve a lot of cleanup and better use of Twine/StringRef.

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

show more ...

[AIX] Turn -fdata-sections on by default in Clang

Summary:

This patch does the following:
1. Make InitTargetOptionsFromCodeGenFlags() accepts Triple as a
parameter, because some options' default v

[AIX] Turn -fdata-sections on by default in Clang

Summary:

This patch does the following:
1. Make InitTargetOptionsFromCodeGenFlags() accepts Triple as a
parameter, because some options' default value is triple dependant.
2. DataSections is turned on by default on AIX for llc.
3. Test cases change accordingly because of the default behaviour change.
4. Clang Driver passes in -fdata-sections by default on AIX.

Reviewed By: MaskRay, DiggerLin

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

show more ...

llvm-isel-fuzzer.cpp - fix implicit CommandLine.h dependency. NFC.

llvm-isel-fuzzer uses cl::opt but don't include CommandLine.h.

Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration

MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain
cl::opt with static storage.
These

Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration

MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain
cl::opt with static storage.
These headers are meant to be incuded by tools to make it easier to parametrize
codegen/mc.

However, these headers are also included in at least two libraries: lldCommon
and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference
to the options, and lldCommon holds another reference. Linking the two in a
single executable, as zig does[0], results in a double registration.

This patch explores an other approach: the .inc files are moved to regular
files, and the registration happens on-demand through static declaration of
options in the constructor of a static object.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5

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

show more ...

Move CodeGenFileType enum to Support/CodeGen.h

Avoids the need to include TargetMachine.h from various places just for
an enum. Various other enums live here, such as the optimization level,
TLS mod

Move CodeGenFileType enum to Support/CodeGen.h

Avoids the need to include TargetMachine.h from various places just for
an enum. Various other enums live here, such as the optimization level,
TLS model, etc. Data suggests that this change probably doesn't matter,
but it seems nice to have anyway.

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

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

CodeGen: Add a dwo output file argument to addPassesToEmitFile and hook it up to dwo output.

Part of PR37466.

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

llvm-svn: 332881

Rename *CommandFlags.def to *CommandFlags.inc

These aren't the .def style files used in LLVM that require a macro
defined before their inclusion - they're just basic non-modular includes
to stamp ou

Rename *CommandFlags.def to *CommandFlags.inc

These aren't the .def style files used in LLVM that require a macro
defined before their inclusion - they're just basic non-modular includes
to stamp out command line flag variables.

llvm-svn: 329840

show more ...

[llvm-opt-fuzzer] Avoid adding incorrect inputs to the fuzzer corpus

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

llvm-svn: 324225

Remove redundant includes from tools.

llvm-svn: 320631

Rename CommandFlags.h -> CommandFlags.def

Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what th

Rename CommandFlags.h -> CommandFlags.def

Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what they should be) so can't be included more than once in a
program.

llvm-svn: 319082

show more ...

[FuzzMutate] NFC. Move parseModule and writeModule from llvm-isel-fuzzer into FuzzMutate.
This is to be able to reuse them in the llvm-opt-fuzzer.

llvm-svn: 318407

fix llvm-isel-fuzzer: LLVMFuzzerTestOneInput should never return non-zero (according to the contract)

llvm-svn: 315933

Re-commit "llvm-isel-fuzzer: Handle a subset of backend flags in the exec name"

Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you

Re-commit "llvm-isel-fuzzer: Handle a subset of backend flags in the exec name"

Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer=aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer=x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.

Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.

This re-applies 315545 using "=" instead of ":" as a separator for
arguments.

llvm-svn: 315557

show more ...

Revert r315545 "llvm-isel-fuzzer: Handle a subset of backend flags in the executable name"

It broke some tests on Windows:

Failing Tests (4):
LLVM :: tools/llvm-isel-fuzzer/execname-options.ll

Revert r315545 "llvm-isel-fuzzer: Handle a subset of backend flags in the executable name"

It broke some tests on Windows:

Failing Tests (4):
LLVM :: tools/llvm-isel-fuzzer/execname-options.ll
LLVM :: tools/llvm-isel-fuzzer/missing-triple.ll
LLVM :: tools/llvm-isel-fuzzer/x86-empty-bc.ll
LLVM :: tools/llvm-isel-fuzzer/x86-empty.ll

> llvm-isel-fuzzer: Handle a subset of backend flags in the executable name
>
> Here we add a secondary option parser to llvm-isel-fuzzer (and provide
> it for use with other fuzzers). With this, you can copy the fuzzer to
> a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
> AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
> flags required. This should be useful for running these in OSS-Fuzz.
>
> Note that this handrolls a subset of cl::opts to recognize, rather
> than embedding a complete command parser for argv[0]. If we find we
> really need the flexibility of handling arbitrary options at some
> point we can rethink this.

llvm-svn: 315554

show more ...

llvm-isel-fuzzer: Handle a subset of backend flags in the executable name

Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can co

llvm-isel-fuzzer: Handle a subset of backend flags in the executable name

Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.

Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.

llvm-svn: 315545

show more ...

Move some CLI utils out of llvm-isel-fuzzer and into the library

FuzzMutate might not be the best place for these, but it makes more
sense than an entirely new library for now. This will make settin

Move some CLI utils out of llvm-isel-fuzzer and into the library

FuzzMutate might not be the best place for these, but it makes more
sense than an entirely new library for now. This will make setting up
fuzz targets with consistent CLI handling easier.

llvm-svn: 312425

show more ...