[IR] Accept GEPNoWrapFlags in creation APIs

Add overloads of GetElementPtrInst::Create() that accept
GEPNoWrapFlags, and switch the bool parameters in IRBuilder to
accept it instead as well.

As a s

[IR] Accept GEPNoWrapFlags in creation APIs

Add overloads of GetElementPtrInst::Create() that accept
GEPNoWrapFlags, and switch the bool parameters in IRBuilder to
accept it instead as well.

As a sample use, switch GEP i8 canonicalization in InstCombine to
preserve the original flags.

show more ...

[IRBuilder] Migrate fcmp to folding API

This was one of the last leftovers still using a Create-style
instead of Fold-style API. Convert FoldICmp into FoldCmp so it
can handle both icmp and fcmp.

[IRBuilder] Fold binary intrinsics (#80743)

Fixes https://github.com/llvm/llvm-project/issues/61240.

[IRBuilder] Migrate most casts to folding API

Migrate creation of most casts to use the FoldXYZ rather than
CreateXYZ style APIs. This means that InstSimplifyFolder now
works for these, which is wha

[IRBuilder] Migrate most casts to folding API

Migrate creation of most casts to use the FoldXYZ rather than
CreateXYZ style APIs. This means that InstSimplifyFolder now
works for these, which is what accounts for the AMDGPU test changes.

show more ...

[IRBuilder] Migrate fneg to fold infrastructure

Make use of a single FoldUnOpFMF() API, though in practice FNeg
is the only unary operation that exists.

This is likely NFC in practice, because user

[IRBuilder] Migrate fneg to fold infrastructure

Make use of a single FoldUnOpFMF() API, though in practice FNeg
is the only unary operation that exists.

This is likely NFC in practice, because users of InstSimplifyFolder
don't create fneg.

show more ...

[IRBuilder] Move CreateNeg() to fold API

Remove the CreateNeg() method from IRBuilderFolder and base it on
CreateSub(0, V) instead, which will call FoldNoWrapBinaryOp().

May not be NFC if InstSimpl

[IRBuilder] Move CreateNeg() to fold API

Remove the CreateNeg() method from IRBuilderFolder and base it on
CreateSub(0, V) instead, which will call FoldNoWrapBinaryOp().

May not be NFC if InstSimplifyFolder is used.

show more ...

[IRBuilder] Move CreateNot() to fold API

Drop the IRBuilderFolder method entirely and base this on
CreateXor(V, -1) instead, so this will now go through FoldBinOp.

May not be NFC if the InstSimplif

[IRBuilder] Move CreateNot() to fold API

Drop the IRBuilderFolder method entirely and base this on
CreateXor(V, -1) instead, so this will now go through FoldBinOp.

May not be NFC if the InstSimplifyBuilder is used.

show more ...

[llvm] Fix the modules build

Fixes error: missing '#include "llvm/IR/FMF.h"'; 'FastMathFlags' must be
defined before it is used in llvm/include/llvm/IR/NoFolder.h.

[IRBuilder] Migrate all binops to folding API

Migrate all binops to use FoldXYZ rather than CreateXYZ APIs,
which are compatible with InstSimplifyFolder and fallible constant
folding.

Rather than c

[IRBuilder] Migrate all binops to folding API

Migrate all binops to use FoldXYZ rather than CreateXYZ APIs,
which are compatible with InstSimplifyFolder and fallible constant
folding.

Rather than continuing to add one method for every single operator,
add a generic FoldBinOp (plus variants for nowrap, exact and fmf
operators), which we would need anyway for CreateBinaryOp.

This change is not NFC because IRBuilder with InstSimplifyFolder
may perform more folding. However, this patch changes SCEVExpander
to not use the folder in InsertBinOp to minimize practical impact
and keep this change as close to NFC as possible.

show more ...

[IRBuilder] Migrate div/rem to use fold infrastructure

Migrate udiv, sdiv, urem, and srem to use the FoldXYZ rather than
the CreateXYZ infrastructure.

[IRBuilder] Migrate vector operations to fold infrastructure

Migrate extractelement, insertelement and shufflevector to use the
FoldXYZ rather than CreateXYZ APIs.

This is probably NFC in practice,

[IRBuilder] Migrate vector operations to fold infrastructure

Migrate extractelement, insertelement and shufflevector to use the
FoldXYZ rather than CreateXYZ APIs.

This is probably NFC in practice, because the places using
InstSimplifyFolder probably aren't using vector operations.

show more ...

[IRBuilder] Move insertvalue/extractvalue to fold infrastructure

Move from the old CreateXYZ() to the new FoldXYZ() mechanism.

This change is likely NFC in practice, because I don't think that
the

[IRBuilder] Move insertvalue/extractvalue to fold infrastructure

Move from the old CreateXYZ() to the new FoldXYZ() mechanism.

This change is likely NFC in practice, because I don't think that
the places using InstSimplifyFolder use insertvalue/extractvalue.

show more ...

[IRBuilder] Migrate and-folding to value-based FoldAnd.

Similar to the migration of or-folding to FoldOr, there are a few cases
where the fold in IRBuilder::CreateAnd triggered directly. Those have

[IRBuilder] Migrate and-folding to value-based FoldAnd.

Similar to the migration of or-folding to FoldOr, there are a few cases
where the fold in IRBuilder::CreateAnd triggered directly. Those have
been updated.

Reviewed By: nikic

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

show more ...

[IRBuilder] Migrate select-folding to value-based FoldSelect.

Reviewed By: lebedev.ri

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

[IRBuilder] Migrate gep-folding to value-based FoldGEP.

Depends on D117038.

Reviewed By: lebedev.ri

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

[IRBuilder] Migrate icmp-folding to value-based FoldICmp.

Depends on D116935.

Reviewed By: nikic, lebedev.ri

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

[IRBuilder] Migrate add-folding to value-based FoldAdd.

Depends on D116935.

Reviewed By: nikic

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

[IRBuilder] Introduce folder using inst-simplify, use for Or fold.

Alternative to D116817.

This introduces a new value-based folding interface for Or (FoldOr),
which takes 2 values and returns an e

[IRBuilder] Introduce folder using inst-simplify, use for Or fold.

Alternative to D116817.

This introduces a new value-based folding interface for Or (FoldOr),
which takes 2 values and returns an existing Value or a constant if the
Or can be simplified. Otherwise nullptr is returned. This replaces the
more restrictive CreateOr which takes 2 constants.

This is the used to implement a folder that uses InstructionSimplify.
The logic to simplify `Or` instructions is moved there. Subsequent
patches are going to transition other CreateXXX to the more general
FoldXXX interface.

Reviewed By: nikic, lebedev.ri

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

show more ...

Remove "mask" operand from shufflevector.

Instead, represent the mask as out-of-line data in the instruction. This
should be more efficient in the places that currently use
getShuffleVector(), and p

Remove "mask" operand from shufflevector.

Instead, represent the mask as out-of-line data in the instruction. This
should be more efficient in the places that currently use
getShuffleVector(), and paves the way for further changes to add new
shuffles for scalable vectors.

This doesn't change the syntax in textual IR. And I don't currently plan
to change the bitcode encoding in this patch, although we'll probably
need to do something once we extend shufflevector for scalable types.

I expect that once this is finished, we can then replace the raw "mask"
with something more appropriate for scalable vectors. Not sure exactly
what this looks like at the moment, but there are a few different ways
we could handle it. Maybe we could try to describe specific shuffles.
Or maybe we could define it in terms of a function to convert a fixed-length
array into an appropriate scalable vector, using a "step", or something
like that.

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

show more ...

Reapply "[IRBuilder] Virtualize IRBuilder"

Relative to the original commit, this fixes some warnings,
and is based on the deletion of the IRBuilder copy constructor
in D74693. The automatic copy con

Reapply "[IRBuilder] Virtualize IRBuilder"

Relative to the original commit, this fixes some warnings,
and is based on the deletion of the IRBuilder copy constructor
in D74693. The automatic copy constructor would no longer be
safe.

-----

Related llvm-dev thread:
http://lists.llvm.org/pipermail/llvm-dev/2020-February/138951.html

This patch moves the IRBuilder from templating over the constant
folder and inserter towards making both of these virtual.
There are a couple of motivations for this:

1. It's not possible to share code between use-sites that use
different IRBuilder folders/inserters (short of templating the code
and moving it into headers).
2. Methods currently defined on IRBuilderBase (which is not templated)
do not use the custom inserter, resulting in subtle bugs (e.g.
incorrect InstCombine worklist management). It would be possible to
move those into the templated IRBuilder, but...
3. The vast majority of the IRBuilder implementation has to live
in the header, because it depends on the template arguments.
4. We have many unnecessary dependencies on IRBuilder.h,
because it is not easy to forward-declare. (Significant parts of
the backend depend on it via TargetLowering.h, for example.)

This patch addresses the issue by making the following changes:

* IRBuilderDefaultInserter::InsertHelper becomes virtual.
IRBuilderBase accepts a reference to it.
* IRBuilderFolder is introduced as a virtual base class. It is
implemented by ConstantFolder (default), NoFolder and TargetFolder.
IRBuilderBase has a reference to this as well.
* All the logic is moved from IRBuilder to IRBuilderBase. This means
that methods can in the future replace their IRBuilder<> & uses
(or other specific IRBuilder types) with IRBuilderBase & and thus
be usable with different IRBuilders.
* The IRBuilder class is now a thin wrapper around IRBuilderBase.
Essentially it only stores the folder and inserter and takes care
of constructing the base builder.

What this patch doesn't do, but should be simple followups after this change:

* Fixing use of the inserter for creation methods originally defined
on IRBuilderBase.
* Replacing IRBuilder<> uses in arguments with IRBuilderBase, where useful.
* Moving code from the IRBuilder header to the source file.

From the user perspective, these changes should be mostly transparent:
The only thing that consumers using a custom inserted may need to do is
inherit from IRBuilderDefaultInserter publicly and mark their InsertHelper
as public.

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

show more ...

Revert "[IRBuilder] Virtualize IRBuilder"

This reverts commit 0765d3824d069f37596bc5a890399099b776c2a0.
This reverts commit 1b04866a3db9f816a559860f941da067fe1eccf1.

Relevant looking crashes observ

Revert "[IRBuilder] Virtualize IRBuilder"

This reverts commit 0765d3824d069f37596bc5a890399099b776c2a0.
This reverts commit 1b04866a3db9f816a559860f941da067fe1eccf1.

Relevant looking crashes observed on:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win

show more ...

[IRBuilder] Virtualize IRBuilder

Related llvm-dev thread:
http://lists.llvm.org/pipermail/llvm-dev/2020-February/138951.html

This patch moves the IRBuilder from templating over the constant
folder

[IRBuilder] Virtualize IRBuilder

Related llvm-dev thread:
http://lists.llvm.org/pipermail/llvm-dev/2020-February/138951.html

This patch moves the IRBuilder from templating over the constant
folder and inserter towards making both of these virtual.
There are a couple of motivations for this:

1. It's not possible to share code between use-sites that use
different IRBuilder folders/inserters (short of templating the code
and moving it into headers).
2. Methods currently defined on IRBuilderBase (which is not templated)
do not use the custom inserter, resulting in subtle bugs (e.g.
incorrect InstCombine worklist management). It would be possible to
move those into the templated IRBuilder, but...
3. The vast majority of the IRBuilder implementation has to live
in the header, because it depends on the template arguments.
4. We have many unnecessary dependencies on IRBuilder.h,
because it is not easy to forward-declare. (Significant parts of
the backend depend on it via TargetLowering.h, for example.)

This patch addresses the issue by making the following changes:

* IRBuilderDefaultInserter::InsertHelper becomes virtual.
IRBuilderBase accepts a reference to it.
* IRBuilderFolder is introduced as a virtual base class. It is
implemented by ConstantFolder (default), NoFolder and TargetFolder.
IRBuilderBase has a reference to this as well.
* All the logic is moved from IRBuilder to IRBuilderBase. This means
that methods can in the future replace their IRBuilder<> & uses
(or other specific IRBuilder types) with IRBuilderBase & and thus
be usable with different IRBuilders.
* The IRBuilder class is now a thin wrapper around IRBuilderBase.
Essentially it only stores the folder and inserter and takes care
of constructing the base builder.

What this patch doesn't do, but should be simple followups after this change:

* Fixing use of the inserter for creation methods originally defined
on IRBuilderBase.
* Replacing IRBuilder<> uses in arguments with IRBuilderBase, where useful.
* Moving code from the IRBuilder header to the source file.

From the user perspective, these changes should be mostly transparent:
The only thing that consumers using a custom inserted may need to do is
inherit from IRBuilderDefaultInserter publicly and mark their InsertHelper
as public.

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

show more ...

[IRBuilder] Remove more unnecessary NoFolder methods

Split out from D73835. I removed some of these before, but missed
these ones. They are not part of the ConstantFolder interface
and are not going

[IRBuilder] Remove more unnecessary NoFolder methods

Split out from D73835. I removed some of these before, but missed
these ones. They are not part of the ConstantFolder interface
and are not going to be used by the IRBuilder.

show more ...

[IRBuilder] Add missing NoFolder::CreatePointerBitCastOrAddrSpaceCast(); NFC

Split out from D73835. This method was added to ConstantFolder and
TargetFolder, but not NoFolder.

[IRBuilder] Remove unnecessary NoFolder methods; NFCI

Split out from D73835: These methods are not part of the
ConstantFolder API and as such don't serve a purpose.