[IR][unittests] Replace of PointerType::get(Type) with opaque version (NFC) (#123621)

In accordance with https://github.com/llvm/llvm-project/issues/123569

Fix typo "instrinsic" (#112899)

[FuzzMutate] Handle BB without predecessor, avoid insertion after `musttail call`, avoid sinking token type

FuzzMutate didn't consider some corner cases and leads to mutation failure when mutating s

[FuzzMutate] Handle BB without predecessor, avoid insertion after `musttail call`, avoid sinking token type

FuzzMutate didn't consider some corner cases and leads to mutation failure when mutating some modules.
This patch fixes 3 bugs:

- Add null check when encountering basic blocks without predecessor to avoid segmentation fault
- Avoid insertion after `musttail call` instruction
- Avoid sinking token type

Unit tests are also added.

Reviewed By: Peter

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

show more ...

[FuzzMutate] Skip EHPad during mutation and avoid replacing callee with pointer when sinking

This patch addresses 2 problems:

- In `ShuffleBlockStrategy`, when `BB` is an EHPad, `BB.getFirstInserti

[FuzzMutate] Skip EHPad during mutation and avoid replacing callee with pointer when sinking

This patch addresses 2 problems:

- In `ShuffleBlockStrategy`, when `BB` is an EHPad, `BB.getFirstInsertionPt()` will return `BB.end()`, which cannot be dereferenced and will cause crash in following loop.
- In `isCompatibleReplacement`, a call instruction's callee might be replaced by a pointer, causing 2 subproblems:
- we cannot guarantee that the pointer is a function pointer (even if it is, we cannot guarantee it matches the signature).
- after such a replacement, `getCalledFunction` will from then on return `nullptr` (since it's indirect call) which causes Segmentation Fault in the lines below.

This patch fixes the first problem by checking if a block to be mutated is an EHPad in base class `IRMutationStrategy` and skipping mutating it if so.

This patch fixes the second problem by avoiding replacing callee with pointer and adding a null check for indirect calls.

Reviewed By: Peter

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

show more ...

[FuzzMutate] RandomIRBuilder has more source and sink type now.

Source and Sink are required when generating a new instruction.
(Term defined by previous author, in LLVM terms it's probably Use and

[FuzzMutate] RandomIRBuilder has more source and sink type now.

Source and Sink are required when generating a new instruction.
(Term defined by previous author, in LLVM terms it's probably Use and User.)
Previously, only instructions in the same block is considered when taking source and sink.

In this patch, more source and sink types are considered.
For source, we have SrcFromInstInCurBlock, FunctionArgument, InstInDominator, SrcFromGlobalVariable, and NewConstOrStack.
For sink, we have SinkToInstInCurBlock, PointersInDominator, InstInDominatee, NewStore, and SinkToGlobalVariable.

A unit test to make sure source always dominates an instruction, and the instruction always dominates the sink is included.

Reviewed By: arsenm

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

show more ...

Revert "[FuzzMutate] RandomIRBuilder has more source and sink type now."

This reverts commit e0117a3efacf9620408393f162a7795b5e0965d2.

[FuzzMutate] Update unit testing

There are some typos in the previous patch e0117a3efacf that woulc break unit test and CI.
These typos are fixed now.

Signed-off-by: Peter Rong <PeterRong96@gmail.c

[FuzzMutate] Update unit testing

There are some typos in the previous patch e0117a3efacf that woulc break unit test and CI.
These typos are fixed now.

Signed-off-by: Peter Rong <PeterRong96@gmail.com>

show more ...

[FuzzMutate] RandomIRBuilder has more source and sink type now.

Source and Sink are required when generating a new instruction.
(Term defined by previous author, in LLVM terms it's probably Use and

[FuzzMutate] RandomIRBuilder has more source and sink type now.

Source and Sink are required when generating a new instruction.
(Term defined by previous author, in LLVM terms it's probably Use and User.)
Previously, only instructions in the same block is considered when taking source and sink.

In this patch, more source and sink types are considered.
For source, we have SrcFromInstInCurBlock, FunctionArgument, InstInDominator, SrcFromGlobalVariable, and NewConstOrStack.
For sink, we have SinkToInstInCurBlock, PointersInDominator, InstInDominatee, NewStore, and SinkToGlobalVariable.

A unit test to make sure source always dominates an instruction, and the instruction always dominates the sink is included.

Reviewed By: arsenm

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

show more ...

[NFC] Fix "form/from" typos

Reviewed By: #libc, ldionne

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

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

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

show more ...

[RandomIRBuilderTest] Convert to opaque pointers (NFC)

The FirstClassTypes test is no longer relevant with opaque pointers,
or at least not in that form.

[FuzzMutate] Fix a bug in `connectToSink` which might invalidate the whole module.

`connectToSink` uses a value by putting it in a future instruction.
It will replace the operand of a future instruc

[FuzzMutate] Fix a bug in `connectToSink` which might invalidate the whole module.

`connectToSink` uses a value by putting it in a future instruction.
It will replace the operand of a future instruction with the current value.

However, if current value is an `Instruction` and put into a switch case, the module is invalid.
We fix that by only connecting to Br/Switch's condition, and don't touch other operands.

Will have other strategies to mutate other Br/Switch operands to be patched once this patch is passed

Reviewed By: arsenm

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

show more ...

[FuzzMutate] change of format and comment for further code

Signed-off-by: Peter Rong <PeterRong96@gmail.com>

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

[FuzzMutate] Avoid using swifterror as a source operand

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

llvm-svn: 322280

[FuzzMutate] Only generate loads and stores to the first class sized types

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

llvm-svn: 320573

[FuzzMutate] Correctly insert sinks and sources around invoke instructions

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

llvm-svn: 320136

[FuzzMutate] Correctly handle vector types in the insertvalue operation

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

llvm-svn: 319442

[FuzzMutate] Don't use index operands as sinks

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

llvm-svn: 319441

[FuzzMutate] Pick correct index for the insertvalue instruction

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

llvm-svn: 319440

[FuzzMutate] Don't create load as a new source if it doesn't match with the descriptor

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

llvm-svn: 319439