History log of /llvm-project/llvm/lib/FuzzMutate/RandomIRBuilder.cpp (Results 1 – 25 of 30)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 416f1c46 20-Jan-2025 Mats Jun Larsen <mats@jun.codes>

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

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

In order to keep the patch at reasonable size, this

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

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

In order to keep the patch at reasonable size, this PR only covers for
the llvm subproject, unittests excluded.

show more ...


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5
# 3e15bce9 20-Nov-2024 Nuno Lopes <nuno.lopes@tecnico.ulisboa.pt>

[FuzzMutate] replace undef placeholders with poison


Revision tags: llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3
# 75c7bca7 13-Aug-2024 Sergei Barannikov <barannikov88@gmail.com>

[DataLayout] Remove constructor accepting a pointer to Module (#102841)

The constructor initializes `*this` with `M->getDataLayout()`, which
is effectively the same as calling the copy constructor.

[DataLayout] Remove constructor accepting a pointer to Module (#102841)

The constructor initializes `*this` with `M->getDataLayout()`, which
is effectively the same as calling the copy constructor.
There does not seem to be a case where a copy would be necessary.

Pull Request: https://github.com/llvm/llvm-project/pull/102841

show more ...


# 2b1122ea 08-Aug-2024 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][RemoveDIs] Use iterator-insertion in unittests and fuzzer (#102015)

These are the final few places in LLVM that use instruction pointers to
insert instructions -- use iterators instead,

[DebugInfo][RemoveDIs] Use iterator-insertion in unittests and fuzzer (#102015)

These are the final few places in LLVM that use instruction pointers to
insert instructions -- use iterators instead, which is needed for
debug-info correctness in the future. Most of this is a gentle
scattering of getIterator calls or not deref-then-addrofing iterators.
libfuzzer does require a storage change to keep built instruction
positions in a container though. The unit-test changes are very
straightforwards.

This leaves us in a position where libfuzzer can't fuzz on either of
debug-info records, however I don't believe that fuzzing of debug-info
is in scope for the library.

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# 69365ae5 14-Jul-2023 Nikita Popov <npopov@redhat.com>

[RandomIRBuilder] Remove use of getNonOpaquePointerElementType() (NFC)


# 61e0822e 14-Jul-2023 Nikita Popov <npopov@redhat.com>

[llvm][clang] Remove uses of isOpaquePointerTy() (NFC)

This now always returns true (for pointer types).


Revision tags: llvmorg-16.0.6
# 258cd1fc 02-Jun-2023 Henry Yu <hnryu@ucdavis.edu>

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


Revision tags: llvmorg-16.0.5, llvmorg-16.0.4
# a5eae043 04-May-2023 Mikael Holmen <mikael.holmen@ericsson.com>

[FuzzMutate] Remove unused variable [NFC]

gcc warned with
../lib/FuzzMutate/RandomIRBuilder.cpp:319:28: warning: unused variable 'PtrTy' [-Wunused-variable]
319 | if (PointerType *PtrT

[FuzzMutate] Remove unused variable [NFC]

gcc warned with
../lib/FuzzMutate/RandomIRBuilder.cpp:319:28: warning: unused variable 'PtrTy' [-Wunused-variable]
319 | if (PointerType *PtrTy = dyn_cast<PointerType>(I.getType()))
| ^~~~~

show more ...


Revision tags: llvmorg-16.0.3
# 66892f25 26-Apr-2023 Henry Yu <hnryu@ucdavis.edu>

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


Revision tags: llvmorg-16.0.2
# 6998b34c 17-Apr-2023 Peter Rong <PeterRong96@gmail.com>

[FuzzMutate] InsertFunctionStrategy

InsertFunctionStrategy does two things:

1. Add a random function declaration or definition to the module. This would replace previously used `createEmptyFunction

[FuzzMutate] InsertFunctionStrategy

InsertFunctionStrategy does two things:

1. Add a random function declaration or definition to the module. This would replace previously used `createEmptyFunction`.
2. Add a random function call between instructions.

Reviewed By: arsenm

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

show more ...


# 64ce140f 17-Apr-2023 Peter Rong <PeterRong96@gmail.com>

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


# a933f600 16-Apr-2023 Peter Rong <PeterRong96@gmail.com>

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

This reverts commit e0117a3efacf9620408393f162a7795b5e0965d2.


Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# e0117a3e 13-Dec-2022 Peter Rong <PeterRong96@gmail.com>

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


# bc277eb1 01-Dec-2022 Peter Rong <PeterRong96@gmail.com>

[FuzzMutate] New InsertCFGStrategy

Mutating CFG is hard as we have to maintain dominator relations.
We avoid this problem by inserting a CFG into a splitted block.

switch, ret, and br instructions

[FuzzMutate] New InsertCFGStrategy

Mutating CFG is hard as we have to maintain dominator relations.
We avoid this problem by inserting a CFG into a splitted block.

switch, ret, and br instructions are generated.

Reviewed By: arsenm

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

show more ...


Revision tags: llvmorg-15.0.6
# 4be08734 29-Nov-2022 Peter Rong <PeterRong96@gmail.com>

[FuzzMutate] New InsertPHINode strategy.

PHI Node can't be modeled like other instructions since its operand
number depends on predecessors. So we have a stand alone strategy for it.

Signed-off-by:

[FuzzMutate] New InsertPHINode strategy.

PHI Node can't be modeled like other instructions since its operand
number depends on predecessors. So we have a stand alone strategy for it.

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

Reviewed By: arsenm

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

show more ...


# 50921a21 29-Nov-2022 Peter Rong <PeterRong96@gmail.com>

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


Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# ed98c1b3 09-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332


# 3c47dd47 10-Mar-2022 Nikita Popov <npopov@redhat.com>

[FuzzMutate] Support opaque pointers

Avoid checks that are irrelevant for opaque pointers, and pick
load/GEP types independently of the pointer type.

The GEP case at least could be done more effici

[FuzzMutate] Support opaque pointers

Avoid checks that are irrelevant for opaque pointers, and pick
load/GEP types independently of the pointer type.

The GEP case at least could be done more efficiently by directly
generating a type, but this would require some significant API
changes.

show more ...


Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init
# aa97bc11 21-Jan-2022 Nikita Popov <npopov@redhat.com>

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecatin

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecating the API.

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2
# 14359ef1 01-Feb-2019 James Y Knight <jyknight@google.com>

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


Revision tags: llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@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 ...


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3
# 9ae926b9 26-Aug-2018 Chandler Carruth <chandlerc@gmail.com>

[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.

This is a bit awkward in a handful of places where we didn't even have
an instruction and now we have to see if we can build one. But on the

[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.

This is a bit awkward in a handful of places where we didn't even have
an instruction and now we have to see if we can build one. But on the
whole, this seems like a win and at worst a reasonable cost for removing
`TerminatorInst`.

All of this is part of the removal of `TerminatorInst` from the
`Instruction` type hierarchy.

llvm-svn: 340701

show more ...


Revision tags: llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1
# d8920b1c 13-Dec-2017 Michael Zolotukhin <mzolotukhin@apple.com>

Remove redundant includes from various places.

llvm-svn: 320629


# d209ff98 13-Dec-2017 Igor Laevsky <igmyrj@gmail.com>

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

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

llvm-svn: 320573


# 76b36d3a 08-Dec-2017 Igor Laevsky <igmyrj@gmail.com>

[FuzzMutate] Correctly insert sinks and sources around invoke instructions

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

llvm-svn: 320136


12