Reapply [IR] Avoid creating icmp/fcmp constant expressions (#92885)

Reapply after https://github.com/llvm/llvm-project/pull/93548,
which should address the lldb failure on macos.

-----

Do not crea

Reapply [IR] Avoid creating icmp/fcmp constant expressions (#92885)

Reapply after https://github.com/llvm/llvm-project/pull/93548,
which should address the lldb failure on macos.

-----

Do not create icmp/fcmp constant expressions in IRBuilder etc anymore,
i.e. treat them as "undesirable". This is in preparation for removing
them entirely.

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

show more ...

Revert "[IR] Avoid creating icmp/fcmp constant expressions" (#93087)

Reverts llvm/llvm-project#92885 due to LLDB CI breakages.

[IR] Avoid creating icmp/fcmp constant expressions (#92885)

Do not create icmp/fcmp constant expressions in IRBuilder etc anymore,
i.e. treat them as "undesirable". This is in preparation for remov

[IR] Avoid creating icmp/fcmp constant expressions (#92885)

Do not create icmp/fcmp constant expressions in IRBuilder etc anymore,
i.e. treat them as "undesirable". This is in preparation for removing
them entirely.

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

show more ...

[SCCP] Refine trunc with nsw/nuw flags (#87926)

Following #85592, add support for nsw/nuw flags of trunc in SCCP.

[SCCP] Use range info to prove AddInst has NSW flag.

This patch updates SCCP to use the value ranges of AddInst operands to
try to prove the AddInst does not overflow in the signed sense and
adds th

[SCCP] Use range info to prove AddInst has NSW flag.

This patch updates SCCP to use the value ranges of AddInst operands to
try to prove the AddInst does not overflow in the signed sense and
adds the NSW flag. The reasoning is done with
makeGuaranteedNoWrapRegion (thanks @nikic for point it out!).

Follow-ups will include extending this to more
OverflowingBinaryOperators.

Depends on D142387.

Reviewed By: nikic

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

show more ...

Recommit "[SCCP] Use range info to prove AddInst has NUW flag."

This reverts commit 531756b9544b3e164b9ab998292fce3ebbc7c746.

The recommitted version fixes a crash when one of the operands is a
con

Recommit "[SCCP] Use range info to prove AddInst has NUW flag."

This reverts commit 531756b9544b3e164b9ab998292fce3ebbc7c746.

The recommitted version fixes a crash when one of the operands is a
constant other than a ConstantInt. Test for that case have been added
in 5b16cd97b8e1c273.

It splits off the new logic into a separate function because setting the
flags is quite different compared to the other cases handled in replaceSignedInst
which all require replacing an existing instruction.

It also guards makeGuaranteedNoWrapRegion by `if (!Inst.hasNoUnsignedWrap())`
as discussed in the review.

Fixes #60280.
Fixes #60278.

Original message:
This patch updates SCCP to use the value ranges of AddInst operands to
try to prove the AddInst does not overflow in the unsigned sense and
adds the NUW flag. The reasoning is done with
makeGuaranteedNoWrapRegion (thanks @nikic for point it out!).

Follow-ups will include adding NSW and extension to more
OverflowingBinaryOperators.

Reviewed By: nikic

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

show more ...

Revert "Recommit "[SCCP] Use range info to prove AddInst has NUW flag.""

This reverts commit 366e1faa2fffd5b2284e25b09b6a26bcd2aca2b7.

It looks like this exposes another set of crashes on the build

Revert "Recommit "[SCCP] Use range info to prove AddInst has NUW flag.""

This reverts commit 366e1faa2fffd5b2284e25b09b6a26bcd2aca2b7.

It looks like this exposes another set of crashes on the buildbots.
Revert while I investigate.

show more ...

Recommit "[SCCP] Use range info to prove AddInst has NUW flag."

The recommitted version fixes a crash when one of the operands is a
constant other than a ConstantInt. Test for that case have been ad

Recommit "[SCCP] Use range info to prove AddInst has NUW flag."

The recommitted version fixes a crash when one of the operands is a
constant other than a ConstantInt. Test for that case have been added
in 5b16cd97b8e1c273.

It splits off the new logic into a separate function because setting the
flags is quite different compared to the other cases handled in replaceSignedInst
which all require replacing an existing instruction. Instructions are
now refined before any replacements are done, which has the advantage
that we should have lattice values for all operands (fixing the crashes
and simplifies the logic) and also allows optimizing more cases where one
of the operands also gets replaced (see improvements in
@sge_with_sext_to_zext_conversion).

It also guards makeGuaranteedNoWrapRegion by `if (!Inst.hasNoUnsignedWrap())`
as discussed in the review.

Fixes #60280.
Fixes #60278.

Original message:
This patch updates SCCP to use the value ranges of AddInst operands to
try to prove the AddInst does not overflow in the unsigned sense and
adds the NUW flag. The reasoning is done with
makeGuaranteedNoWrapRegion (thanks @nikic for point it out!).

Follow-ups will include adding NSW and extension to more
OverflowingBinaryOperators.

Reviewed By: nikic

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

show more ...

Revert "[SCCP] Use range info to prove AddInst has NUW flag."

This reverts commit de122cb920080fd9e24b2777114271fbef932d5e.

This change causes assertion failures in many of our internal tests.
I ha

Revert "[SCCP] Use range info to prove AddInst has NUW flag."

This reverts commit de122cb920080fd9e24b2777114271fbef932d5e.

This change causes assertion failures in many of our internal tests.
I have filed #60280 for this issue.

show more ...

[SCCP] Use range info to prove AddInst has NUW flag.

This patch updates SCCP to use the value ranges of AddInst operands to
try to prove the AddInst does not overflow in the unsigned sense and
adds

[SCCP] Use range info to prove AddInst has NUW flag.

This patch updates SCCP to use the value ranges of AddInst operands to
try to prove the AddInst does not overflow in the unsigned sense and
adds the NUW flag. The reasoning is done with
makeGuaranteedNoWrapRegion (thanks @nikic for point it out!).

Follow-ups will include adding NSW and extension to more
OverflowingBinaryOperators.

Reviewed By: nikic

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

show more ...

[SCCP] Propagate equality of a not-constant

The equality state of a not-constant can be used to do constant
propagation. For example,
```
define i32 @equal_not_constant(ptr noundef %p, ptr noundef %

[SCCP] Propagate equality of a not-constant

The equality state of a not-constant can be used to do constant
propagation. For example,
```
define i32 @equal_not_constant(ptr noundef %p, ptr noundef %q) {
entry:
%cmp = icmp ne ptr %p, null
br i1 %cmp, label %if.then, label %if.end

if.then: ; preds = %entry
%cmp.then = icmp eq ptr %p, %q
br i1 %cmp.then, label %if.then1, label %if.end

if.then1: ; preds = %if.then
%cmp.then1 = icmp ne ptr %q, null
call void @use(i1 %cmp.then1)
br label %if.end

if.end:
ret i32 0
}

```
In this case, we can fold `%cmp.then1` as `true`.

Reviewed By: nikic

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

show more ...

[ValueLattice] Use DL-aware folding in getCompare()

Use DL-aware ConstantFoldCompareInstOperands() API instead of
ConstantExpr API. The practical effect of this is that SCCP can
now fold comparisons

[ValueLattice] Use DL-aware folding in getCompare()

Use DL-aware ConstantFoldCompareInstOperands() API instead of
ConstantExpr API. The practical effect of this is that SCCP can
now fold comparisons that require DL.

show more ...

[SCCP] Add test for icmp that requires DL to fold (NFC)

[SCCP] Convert tests to opaque pointers (NFC)

Conversion was performed using
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34
plus manual (but uninteresting) fixup.

[SCCP] Don't mark ranges from branch conditions as potentially undef

Now that transforms introducing branch on poison have been removed,
we can stop marking ranges that have been derived from branch

[SCCP] Don't mark ranges from branch conditions as potentially undef

Now that transforms introducing branch on poison have been removed,
we can stop marking ranges that have been derived from branch
conditions as containing undef. The existing comment explains why
this is legal. I've checked that alive2 is happy with SCCP tests
after this change.

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

show more ...

[test] Use -passes syntax when specifying pipeline in some more tests

The legacy PM is deprecated, so update a bunch of lit tests running
opt to use the new PM syntax when specifying the pipeline.
I

[test] Use -passes syntax when specifying pipeline in some more tests

The legacy PM is deprecated, so update a bunch of lit tests running
opt to use the new PM syntax when specifying the pipeline.
In this patch focus has been put on test cases for ConstantMerge,
ConstraintElimination, CorrelatedValuePropagation, GlobalDCE,
GlobalOpt, SCCP, TailCallElim and PredicateInfo.

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

show more ...

[PredicateInfo] Handle logical and/or

Teach PredicateInfo to handle logical and/or the same way as
bitwise and/or. This allows handling logical and/or inside IPSCCP
and NewGVN.

[PredicateInfo][SCCP][NewGVN] Add tests for logical and/or (NFC)

Duplicate some existing and/or tests using logical form.

[PredicateInfo] Generalize processing of conditions

Branch/assume conditions in PredicateInfo are currently handled in
a rather ad-hoc manner, with some arbitrary limitations. For example,
an `and`

[PredicateInfo] Generalize processing of conditions

Branch/assume conditions in PredicateInfo are currently handled in
a rather ad-hoc manner, with some arbitrary limitations. For example,
an `and` of two `icmp`s will be handled, but an `and` of an `icmp`
and some other condition will not. That also includes the case where
more than two conditions and and'ed together.

This patch makes the handling more general by looking through and/ors
up to a limit and considering all kinds of conditions (though operands
will only be taken for cmps of course).

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

show more ...

[SCCP] Fix misclassified conditions in test (NFC)

Reapply [SCCP] Directly remove non-feasible edges

Reapply with DTU update moved after CFG update, which is a
requirement of the API.

-----

Non-feasible control-flow edges are currently removed by

Reapply [SCCP] Directly remove non-feasible edges

Reapply with DTU update moved after CFG update, which is a
requirement of the API.

-----

Non-feasible control-flow edges are currently removed by replacing
the branch condition with a constant and then calling
ConstantFoldTerminator. This happens in a rather roundabout manner,
by inspecting the users (effectively: predecessors) of unreachable
blocks, and further complicated by the need to explicitly materialize
the condition for "forced" edges. I would like to extend SCCP to
discard switch conditions that are non-feasible based on range
information, but this is incompatible with the current approach
(as there is no single constant we could use.)

Instead, this patch explicitly removes non-feasible edges. It
currently only needs to handle the case where there is a single
feasible edge. The llvm_unreachable() branch will need to be
implemented for the aforementioned switch improvement.

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

show more ...

Revert D84264 "[SCCP] Directly remove non-feasible edges" & 5db5b4bc4394ca247c9eb665e03b851848aa2fbf

It breaks stage-2 build. Clang crashed when compiling
llvm/lib/Target/Hexagon/HexagonFrameLowerin

Revert D84264 "[SCCP] Directly remove non-feasible edges" & 5db5b4bc4394ca247c9eb665e03b851848aa2fbf

It breaks stage-2 build. Clang crashed when compiling
llvm/lib/Target/Hexagon/HexagonFrameLowering.cpp

llvm/Support/GenericDomTree.h eraseNode: Node is not a leaf node

show more ...

[SCCP] Directly remove non-feasible edges

Non-feasible control-flow edges are currently removed by replacing
the branch condition with a constant and then calling
ConstantFoldTerminator. This happen

[SCCP] Directly remove non-feasible edges

Non-feasible control-flow edges are currently removed by replacing
the branch condition with a constant and then calling
ConstantFoldTerminator. This happens in a rather roundabout manner,
by inspecting the users (effectively: predecessors) of unreachable
blocks, and further complicated by the need to explicitly materialize
the condition for "forced" edges. I would like to extend SCCP to
discard switch conditions that are non-feasible based on range
information, but this is incompatible with the current approach
(as there is no single constant we could use.)

Instead, this patch explicitly removes non-feasible edges. It
currently only needs to handle the case where there is a single
feasible edge. The llvm_unreachable() branch will need to be
implemented for the aforementioned switch improvement.

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

show more ...

[SCCP] Use conditional info with AND/OR branch conditions.

Currently SCCP does not combine the information of conditions joined by
AND in the true branch or OR in the false branch.

For branches on

[SCCP] Use conditional info with AND/OR branch conditions.

Currently SCCP does not combine the information of conditions joined by
AND in the true branch or OR in the false branch.

For branches on AND, 2 copies will be inserted for the true branch, with
one being the operand of the other as in the code below. We can combine
the information using intersection. Note that for the OR case, the
copies are inserted in the false branch, where using intersection is
safe as well.

define void @foo(i32 %a) {
entry:
%lt = icmp ult i32 %a, 100
%gt = icmp ugt i32 %a, 20
%and = and i1 %lt, %gt
; Has predicate info
; branch predicate info { TrueEdge: 1 Comparison: %lt = icmp ult i32 %a, 100 Edge: [label %entry,label %true] }
%a.0 = call i32 @llvm.ssa.copy.140247425954880(i32 %a)
; Has predicate info
; branch predicate info { TrueEdge: 1 Comparison: %gt = icmp ugt i32 %a, 20 Edge: [label %entry,label %false] }
%a.1 = call i32 @llvm.ssa.copy.140247425954880(i32 %a.0)
br i1 %and, label %true, label %false

true: ; preds = %entry
call void @use(i32 %a.1)
%true.1 = icmp ne i32 %a.1, 20
call void @use.i1(i1 %true.1)
ret void

false: ; preds = %entry
call void @use(i32 %a.1)
ret void
}

Reviewers: efriedma, davide, mssimpso, nikic

Reviewed By: nikic

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

show more ...

Infer alignment of unmarked loads in IR/bitcode parsing.

For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the I

Infer alignment of unmarked loads in IR/bitcode parsing.

For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.

The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.

Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.

This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.

Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.

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

show more ...