[MergeFuncs] Handle ConstantRangeList attributes

Support comparison of ConstantRangeList attributes in
FunctionComparator.

[Utils] Remove unused includes (NFC) (#114748)

Identified with misc-include-cleaner.

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...

[IR] Remove support for icmp and fcmp constant expressions (#93038)

Remove support for the icmp and fcmp constant expressions.

This is part of:
https://discourse.llvm.org/t/rfc-remove-most-const

[IR] Remove support for icmp and fcmp constant expressions (#93038)

Remove support for the icmp and fcmp constant expressions.

This is part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179

As usual, many of the updated tests will no longer test what they were
originally intended to -- this is hard to preserve when constant
expressions get removed, and in many cases just impossible as the
existence of a specific kind of constant expression was the cause of the
issue in the first place.

show more ...

[IR] Add getelementptr nusw and nuw flags (#90824)

This implements the `nusw` and `nuw` flags for `getelementptr` as
proposed at
https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelem

[IR] Add getelementptr nusw and nuw flags (#90824)

This implements the `nusw` and `nuw` flags for `getelementptr` as
proposed at
https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelementptr/78672.

The three possible flags are encapsulated in the new `GEPNoWrapFlags`
class. Currently this class has a ctor from bool, interpreted as the
InBounds flag. This ctor should be removed in the future, as code gets
migrated to handle all flags.

There are a few places annotated with `TODO(gep_nowrap)`, where I've had
to touch code but opted to not infer or precisely preserve the new
flags, so as to keep this as NFC as possible and make sure any changes
of that kind get test coverage when they are made.

show more ...

[NFC] Reduce copies created of ConstantRange when getting ConstantRangeAttributes (#90335)

Think that it can be good to reduce the number of copies created when
working with ConstantRangeAttributes.

[MergeFunc] Handle ConstantRange attributes (#88584)

It is possible to update
[AttributeImpl::operator<](https://github.com/andjo403/llvm-project/blob/a9da350aadfb5c86d36ae18398471558b22c1309/llvm

[MergeFunc] Handle ConstantRange attributes (#88584)

It is possible to update
[AttributeImpl::operator<](https://github.com/andjo403/llvm-project/blob/a9da350aadfb5c86d36ae18398471558b22c1309/llvm/lib/IR/Attributes.cpp#L744)
instead but feels strange to say that a range is less then an other
range.

show more ...

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the representation of the `inrange` attribute, which
is used for vtable splitting.

Currently, inrange is specified as follows:

```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2)
```

The `inrange` is placed on a GEP index, and all accesses must be "in
range" of that index. The new representation is as follows:

```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2)
```

This specifies which offsets are "in range" of the GEP result. The new
representation will continue working when canonicalizing to ptradd
representation:

```
getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48)
```

The inrange offsets are relative to the return value of the GEP. An
alternative design could make them relative to the source pointer
instead. The result-relative format was chosen on the off-chance that we
want to extend support to non-constant GEPs in the future, in which case
this variant is more expressive.

This implementation "upgrades" the old inrange representation in bitcode
by simply dropping it. This is a very niche feature, and I don't think
trying to upgrade it is worthwhile. Let me know if you disagree.

show more ...

[MergeFunc] Fix comparison of constant expressions

Functions using different constant expressions were incorrectly
merged, because a lot of state was missing from the comparison,
including the opcod

[MergeFunc] Fix comparison of constant expressions

Functions using different constant expressions were incorrectly
merged, because a lot of state was missing from the comparison,
including the opcode, the comparison predicate, the GEP element
type, as well as the inbounds, inrange and nowrap poison flags.

show more ...

[FunctionComparator] Differentiate instructions passing different MDStrings (#69543)

Prior to this patch, differing metadata operands to two otherwise
identical instructions was not enough to consi

[FunctionComparator] Differentiate instructions passing different MDStrings (#69543)

Prior to this patch, differing metadata operands to two otherwise
identical instructions was not enough to consider the instructions
different in the eyes of the function comparator. This breaks LLVM
virtual function elimination, among other features.

In this patch, we handle the case where two associated operands are
MDStrings of different value. This patch does not differentiate more
complex metadata operands.

---------

Co-authored-by: Nuri Amari <nuriamari@fb.com>

show more ...

Reland "[NFCi][MergeFunctions] Consolidate Hashing Functions"

This is a reland of 28134a29fdedd8972acdfb39223571ddcc15dc59 which was
reverted due to behavioral differences between 32 and 64 bit buil

Reland "[NFCi][MergeFunctions] Consolidate Hashing Functions"

This is a reland of 28134a29fdedd8972acdfb39223571ddcc15dc59 which was
reverted due to behavioral differences between 32 and 64 bit builds that
have since been fixed.

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

show more ...

Revert "[NFCi][MergeFunctions] Consolidate Hashing Functions"

This reverts commit 28134a29fdedd8972acdfb39223571ddcc15dc59.

This patch was causing build failures on multiple buildbots on 32-bit
arc

Revert "[NFCi][MergeFunctions] Consolidate Hashing Functions"

This reverts commit 28134a29fdedd8972acdfb39223571ddcc15dc59.

This patch was causing build failures on multiple buildbots on 32-bit
architectures. Reverting now so I can deboug out-of-trunk and resubmit
later.

show more ...

[NFCi][MergeFunctions] Consolidate Hashing Functions

A couple years ago, StructuralHash was created, copying the exact
hashing implementation from FunctionComparator (minus a couple small
details/re

[NFCi][MergeFunctions] Consolidate Hashing Functions

A couple years ago, StructuralHash was created, copying the exact
hashing implementation from FunctionComparator (minus a couple small
details/refactorings). Since then, the hashing implementation has not
diverged, but several other areas, like unit testing, have diverged
significantly, with StructuralHash getting more attention in these
areas. This patch aims to consolidate the two hashing functions into
StructuralHash given they do the exact same thing and having less
divergence in areas like unit testing would be beneficial.

The original aim at creating a separate StructuralHash was to make the
implementation divergent and capture additional details like instruction
operands (which neither hashing implementation does currently). The
MergeFunctions pass doesn't need these detaisl, but verification of pass
return values would benefit from this additional data. Setting an option
to calculate these values would allow for divergent behavior where
appropriate while reducing code duplication with little runtime
overhead.

Reviewed By: aeubanks

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

show more ...

[llvm] Use pointer index type for more GEP offsets (pre-codegen)

Many uses of getIntPtrType() were using that type to calculate the
neened type for GEP offset arguments. However, some time ago,
Data

[llvm] Use pointer index type for more GEP offsets (pre-codegen)

Many uses of getIntPtrType() were using that type to calculate the
neened type for GEP offset arguments. However, some time ago,
DataLayout was extended to support pointers where the size of the
pointer is not equal to the size of the values used to index it.

Much code was already migrated to, for example, use getIndexSizeInBits
instead of getPtrSizeInBits, but some rewrites still used
getIntPtrType() to get the type for GEP offsets.

This commit changes uses of getIntPtrType() to getIndexType() where
they are involved in a GEP-related calculation.

In at least one case (bounds check insertion) this resolves a compiler
crash that the new test added here would previously trigger.

This commit does not impact
- C library-related rewriting (memcpy()), which are operating under
the assumption that intptr_t == size_t. While all the mechanisms for
breaking this assumption now exist, doing so is outside the scope of
this commit.
- Code generation and below. Note that the use of getIntPtrType() in
CodeGenPrepare will be changed in a future commit.
- Usage of getIntPtrType() in any backend

Depends on D143435

Reviewed By: arichardson

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

show more ...

[MergeFunc] Don't assume constant metadata operands

We should not call mdconst::extract, unless we know that the
metadata in question is ConstantAsMetadata.

For now we consider all other metadata a

[MergeFunc] Don't assume constant metadata operands

We should not call mdconst::extract, unless we know that the
metadata in question is ConstantAsMetadata.

For now we consider all other metadata as equal. The noalias test
shows that this is not correct, but at least it doesn't crash
anymore.

show more ...

[MergeFuncs] Compare load instruction metadata

MergeFuncs currently merges load instructions with differing
semantically-relevant metadata, e.g. a load that has !nonnull
with one that does not.

Upd

[MergeFuncs] Compare load instruction metadata

MergeFuncs currently merges load instructions with differing
semantically-relevant metadata, e.g. a load that has !nonnull
with one that does not.

Update FunctionComparator to make sure that metadata of both
loads is the same. Alternatively, it would be possilbe to ignore
the metadata during comparison, and then drop it during merging.

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

show more ...

[FuncitonComparator] Clamp StringRef compare output to [-1,1]

The comparison can have different values (but same sign) on big endian
platforms, avoid that to make the unit test green there.

[NFC] Use TypeSize::geFixedValue() instead of TypeSize::getFixedSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[NFC] Cleanup: Remove Function::getBasicBlockList() when not required.

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

Differential Revision: https://r

[NFC] Cleanup: Remove Function::getBasicBlockList() when not required.

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

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

show more ...

[llvm] Handle dso_local_equivalent in FunctionComparator

This addresses https://github.com/llvm/llvm-project/issues/51066.

Prior to this, dso_local_equivalent would lead to an llvm_unreachable in
a

[llvm] Handle dso_local_equivalent in FunctionComparator

This addresses https://github.com/llvm/llvm-project/issues/51066.

Prior to this, dso_local_equivalent would lead to an llvm_unreachable in
a switch in the FunctionComparator. This adds a conservative case in
that switch that just compares the underlying functions.

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

show more ...

[llvm] Qualify auto (NFC)

Identified with readability-qualified-auto.

[FunctionComparator] Use getAlign() instead of getAlignment()

getAlignment() is deprecated.

[NFC][AttributeList] Replace index_begin/end with an iterator

We expose the fact that we rely on unsigned wrapping to iterate through
all indexes. This can be confusing. Rather, keeping it as an
imp

[NFC][AttributeList] Replace index_begin/end with an iterator

We expose the fact that we rely on unsigned wrapping to iterate through
all indexes. This can be confusing. Rather, keeping it as an
implementation detail through an iterator is less confusing and is less
code.

Reviewed By: rnk

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

show more ...

Fix use-of-uninitialized-value in rG75f50e15bf8f

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

[MergeFunctions] fix function attribute comparison in FunctionComparator

The comparison of AttributeSets stopped after seeing a matching type attribute.
Subsequent mismatching attributes were not de

[MergeFunctions] fix function attribute comparison in FunctionComparator

The comparison of AttributeSets stopped after seeing a matching type attribute.
Subsequent mismatching attributes were not detected causing a crash.

show more ...