[InstCombine] clean up commonCastTransforms; NFC

1. Use 'auto' with dyn_cast.
2. Variables start with a capital letter.
3. Use proper punctuation in comments.

llvm-svn: 285200

[InstCombine] Resubmit the combine of A->B->A BitCast and fix for pr27996

The original patch of the A->B->A BitCast optimization was reverted by r274094 because it may cause infinite loop inside com

[InstCombine] Resubmit the combine of A->B->A BitCast and fix for pr27996

The original patch of the A->B->A BitCast optimization was reverted by r274094 because it may cause infinite loop inside compiler https://llvm.org/bugs/show_bug.cgi?id=27996.

The problem is with following code

xB = load (type B);
xA = load (type A);
+yA = (A)xB; B -> A
+zAn = PHI[yA, xA]; PHI
+zBn = (B)zAn; // A -> B
store zAn;
store zBn;

optimizeBitCastFromPhi generates

+zBn = (B)zAn; // A -> B

and expects it will be combined with the following store instruction to another

store zAn

Unfortunately before combineStoreToValueType is called on the store instruction, optimizeBitCastFromPhi is called on the new BitCast again, and this pattern repeats indefinitely.

optimizeBitCastFromPhi only generates BitCast for load/store instructions, only the BitCast before store can cause the reexecution of optimizeBitCastFromPhi, and BitCast before store can easily be handled by InstCombineLoadStoreAlloca.cpp. So the solution to the problem is if all users of a CI are store instructions, we should not do optimizeBitCastFromPhi on it. Then optimizeBitCastFromPhi will not be called on the new BitCast instructions.

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

llvm-svn: 285116

show more ...

Reapply "InstCombine: Reduce trunc (shl x, K) width."

This reapplies r272987 with a fix for infinitely looping
when the truncated value is another shift of a constant.

llvm-svn: 281379

InstCombine: Clean up some trailing whitespace. NFC

llvm-svn: 277793

InstCombine: Replace some never-null pointers with references. NFC

llvm-svn: 277792

[InstCombine] Refactor optimization of zext(or(icmp, icmp)) to enable more aggressive cast-folding

Summary:
InstCombine unfolds expressions of the form `zext(or(icmp, icmp))` to `or(zext(icmp), zext

[InstCombine] Refactor optimization of zext(or(icmp, icmp)) to enable more aggressive cast-folding

Summary:
InstCombine unfolds expressions of the form `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` such that in a later iteration of InstCombine the exposed `zext(icmp)` instructions can be optimized. We now combine this unfolding and the subsequent `zext(icmp)` optimization to be performed together. Since the unfolding doesn't happen separately anymore, we also again enable the folding of `logic(cast(icmp), cast(icmp))` expressions to `cast(logic(icmp, icmp))` which had been disabled due to its interference with the unfolding transformation.

Tested via `make check` and `lnt`.

Background
==========

For a better understanding on how it came to this change we subsequently summarize its history. In commit r275989 we've already tried to enable the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))` which had to be reverted in r276106 because it could lead to an endless loop in InstCombine (also see http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160718/374347.html). The root of this problem is that in `visitZExt()` in InstCombineCasts.cpp there also exists a reverse of the above folding transformation, that unfolds `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` in order to expose `zext(icmp)` operations which would then possibly be eliminated by subsequent iterations of InstCombine. However, before these `zext(icmp)` would be eliminated the folding from r275989 could kick in and cause InstCombine to endlessly switch back and forth between the folding and the unfolding transformation. This is the reason why we now combine the `zext`-unfolding and the elimination of the exposed `zext(icmp)` to happen at one go because this enables us to still allow the cast-folding in `logic(cast(icmp), cast(icmp))` without entering an endless loop again.

Details on the submitted changes
================================

- In `visitZExt()` we combine the unfolding and optimization of `zext` instructions.
- In `transformZExtICmp()` we have to use `Builder->CreateIntCast()` instead of `CastInst::CreateIntegerCast()` to make sure that the new `CastInst` is inserted in a `BasicBlock`. The new calls to `transformZExtICmp()` that we introduce in `visitZExt()` would otherwise cause according assertions to be triggered (in our case this happend, for example, with lnt for the MultiSource/Applications/sqlite3 and SingleSource/Regression/C++/EH/recursive-throw tests). The subsequent usage of `replaceInstUsesWith()` is necessary to ensure that the new `CastInst` replaces the `ZExtInst` accordingly.
- In InstCombineAndOrXor.cpp we again allow the folding of casts on `icmp` instructions.
- The instruction order in the optimized IR for the zext-or-icmp.ll test case is different with the introduced changes.
- The test cases in zext.ll have been adopted from the reverted commits r275989 and r276105.

Reviewers: grosser, majnemer, spatel

Subscribers: eli.friedman, majnemer, llvm-commits

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

Contributed-by: Matthias Reisinger <d412vv1n@gmail.com>
llvm-svn: 277635

show more ...

[ConstnatFolding] Teach the folder how to fold ConstantVector

A ConstantVector can have ConstantExpr operands and vice versa.
However, the folder had no ability to fold ConstantVectors which, in
som

[ConstnatFolding] Teach the folder how to fold ConstantVector

A ConstantVector can have ConstantExpr operands and vice versa.
However, the folder had no ability to fold ConstantVectors which, in
some cases, was an optimization barrier.

Instead, rephrase the folder in terms of Constants instead of
ConstantExprs and teach callers how to deal with failure.

llvm-svn: 277099

show more ...

[InstCombine] Handle failures from ConstantFoldConstantExpression

ConstantFoldConstantExpression returns null when folding fails.

This fixes PR28745.

llvm-svn: 276952

[InstCombine] LogicOpc (zext X), C --> zext (LogicOpc X, C) (PR28476)

The benefits of this change include:
1. Remove DeMorgan-matching code that was added specifically to work-around
the missing

[InstCombine] LogicOpc (zext X), C --> zext (LogicOpc X, C) (PR28476)

The benefits of this change include:
1. Remove DeMorgan-matching code that was added specifically to work-around
the missing transform in http://reviews.llvm.org/rL248634.
2. Makes the DeMorgan transform work for vectors too.
3. Fix PR28476: https://llvm.org/bugs/show_bug.cgi?id=28476

Extending this transform to other casts and other associative operators may
be useful too. See https://reviews.llvm.org/D22421 for a prerequisite for
doing that though.

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

llvm-svn: 276221

show more ...

[InstCombine] Minor cleanup of cast simplification code [NFC]

Summary:
This patch cleans up parts of InstCombine to raise its compliance with the LLVM coding standards and to increase its readabilit

[InstCombine] Minor cleanup of cast simplification code [NFC]

Summary:
This patch cleans up parts of InstCombine to raise its compliance with the LLVM coding standards and to increase its readability. The changes and according rationale are summarized in the following:

- Rename `ShouldOptimizeCast()` to `shouldOptimizeCast()` since functions should start with a lower case letter.

- Move `shouldOptimizeCast()` from InstCombineCasts.cpp to InstCombineAndOrXor.cpp since it's only used there.

- Simplify interface of `shouldOptimizeCast()`.

- Minor code style adaptions in `shouldOptimizeCast()`.

- Remove the documentation on the function definition of `shouldOptimizeCast()` since it just repeats the documentation on its declaration. Also enhance the documentation on its declaration with more information describing its intended use and make it doxygen-compliant.

- Change a comment in `foldCastedBitwiseLogic()` from `fold (logic (cast A), (cast B)) -> (cast (logic A, B))` to `fold logic(cast(A), cast(B)) -> cast(logic(A, B))` since the surrounding comments use this format.

- Remove comment `Only do this if the casts both really cause code to be generated.` in `foldCastedBitwiseLogic()` since it just repeats parts of the documentation of `shouldOptimizeCast()` and does not help to improve readability.

- Simplify the interface of `isEliminableCastPair()`.

- Removed the documentation on the function definition of `isEliminableCastPair()` which only contained obvious statements about its implementation. Instead added more general doxygen-compliant documentation to its declaration.

- Renamed parameter `DoXform` of `transformZExtIcmp()` to `DoTransform` to make its intention clearer.

- Moved documentation of `transformZExtIcmp()` from its definition to its declaration and made it doxygen-compliant.

Reviewers: vtjnash, grosser

Subscribers: majnemer, llvm-commits

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

Contributed-by: Matthias Reisinger
llvm-svn: 275964

show more ...

Revert "InstCombine rule to fold truncs whose value is available"

This reverts commit r274853.
Caused failure in ppcBE build

llvm-svn: 274943

InstCombine rule to fold truncs whose value is available

We can fold truncs whose operand feeds from a load, if the trunc value
is available through a prior load/store.

This change is from: http://

InstCombine rule to fold truncs whose value is available

We can fold truncs whose operand feeds from a load, if the trunc value
is available through a prior load/store.

This change is from: http://reviews.llvm.org/D21246, which folded the
trunc but missed the bitcast or ptrtoint/inttoptr required in the RAUW
call, when the load type didnt match the prior load/store type.

Differential Revision: http://reviews.llvm.org/D21791

llvm-svn: 274853

show more ...

Revert "[InstCombine] Avoid combining the bitcast of a var that is used as both address and result of load instructions"
Revert "[InstCombine] Combine A->B->A BitCast"

as this appears to cause PR279

Revert "[InstCombine] Avoid combining the bitcast of a var that is used as both address and result of load instructions"
Revert "[InstCombine] Combine A->B->A BitCast"

as this appears to cause PR27996 and as discussed in http://reviews.llvm.org/D20847

This reverts commits r270135 and r263734.

llvm-svn: 274094

show more ...

Revert "InstCombine rule to fold trunc when value available"

This reverts commit r273608.

Broke building code with sanitizers, where apparently these kinds of
loads, casts, and truncations are comm

Revert "InstCombine rule to fold trunc when value available"

This reverts commit r273608.

Broke building code with sanitizers, where apparently these kinds of
loads, casts, and truncations are common:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24502
http://crbug.com/623099

llvm-svn: 273703

show more ...

InstCombine rule to fold trunc when value available

Summary:
This instcombine rule folds away trunc operations that have value available from a prior load or store.
This kind of code can be generate

InstCombine rule to fold trunc when value available

Summary:
This instcombine rule folds away trunc operations that have value available from a prior load or store.
This kind of code can be generated as a result of GVN widening the load or from source code as well.

Reviewers: reames, majnemer, sanjoy

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D21246

llvm-svn: 273608

show more ...

Revert "Revert "Revert "InstCombine: Reduce trunc (shl x, K) width."""

This seems to be causing an infinite loop / crash in instcombine
on some bots.

llvm-svn: 273069

Revert "Revert "InstCombine: Reduce trunc (shl x, K) width.""

Reapply r272987. Condition should be in terms of the destination type,
and the flags should not be copied.

llvm-svn: 273045

Revert "InstCombine: Reduce trunc (shl x, K) width."

This reverts commit r272987.

This might be causing crashes on some bots.

llvm-svn: 272990

InstCombine: Reduce trunc (shl x, K) width.

llvm-svn: 272987

[InstCombine] Fix assertion when bitcast is converted to gep

When an aggregate contains an opaque type its size cannot be
determined. This triggers an "Invalid GetElementPtrInst indices for type" as

[InstCombine] Fix assertion when bitcast is converted to gep

When an aggregate contains an opaque type its size cannot be
determined. This triggers an "Invalid GetElementPtrInst indices for type" assert
in function checkGEPType. The fix suppresses the conversion in this case.

http://reviews.llvm.org/D20319

llvm-svn: 270479

show more ...

[InstCombine] Avoid combining the bitcast of a var that is used as both address and result of load instructions

This patch fixes https://llvm.org/bugs/show_bug.cgi?id=27703.

If there is a sequence

[InstCombine] Avoid combining the bitcast of a var that is used as both address and result of load instructions

This patch fixes https://llvm.org/bugs/show_bug.cgi?id=27703.

If there is a sequence of one or more load instructions, each loaded value is used as address of later load instruction, bitcast is necessary to change the value type, don't optimize it.

llvm-svn: 270135

show more ...

[InstCombine] Propagate operand bundles

We neglected to transfer operand bundles for some transforms. These
were found via inspection, I'll try to come up with some test cases.

llvm-svn: 268010

[InstCombine] Combine A->B->A BitCast


This patch enhances InstCombine to handle following case:

A -> B bitcast
PHI
B -> A bitcast

llvm-svn: 263734

Revert "[InstCombine] Combine A->B->A BitCast"

This reverts commit r262670 due to compile failure.

llvm-svn: 262916

[InstCombine] Combine A->B->A BitCast

This patch enhances InstCombine to handle following case:

A -> B bitcast
PHI
B -> A bitcast

llvm-svn: 262670