revert r262424 because there's a *clang test* for AArch64 that checks -O3 asm output
that is broken by this change

llvm-svn: 262440

[InstCombine] convert 'isPositive' and 'isNegative' vector comparisons to shifts (PR26701)

As noted in the code comment, I don't think we can do the same transform that we do for
*scalar* integers c

[InstCombine] convert 'isPositive' and 'isNegative' vector comparisons to shifts (PR26701)

As noted in the code comment, I don't think we can do the same transform that we do for
*scalar* integers comparisons to *vector* integers comparisons because it might pessimize
the general case.

Exhibit A for an incomplete integer comparison ISA remains x86 SSE/AVX: it only has EQ and GT
for integer vectors.

But we should now recognize all the variants of this construct and produce the optimal code
for the cases shown in:
https://llvm.org/bugs/show_bug.cgi?id=26701


llvm-svn: 262424

show more ...

function names start with a lowercase letter; NFC

llvm-svn: 259425

fix formatting; NFC

llvm-svn: 256645

[InstCombine] Adding "\n" to debug output. NFC.

Summary:
[InstCombine] Adding '\n' to debug output. NFC.

Patch by Zhaoshi Zheng <zhaoshiz@codeaurora.org>

Reviewers: apazos, majnemer, weimingz

Sub

[InstCombine] Adding "\n" to debug output. NFC.

Summary:
[InstCombine] Adding '\n' to debug output. NFC.

Patch by Zhaoshi Zheng <zhaoshiz@codeaurora.org>

Reviewers: apazos, majnemer, weimingz

Subscribers: arsenm, llvm-commits

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

llvm-svn: 255920

show more ...

getParent() ^ 3 == getModule() ; NFCI

llvm-svn: 255511

[InstCombine] fold trunc ([lshr] (bitcast vector) ) --> extractelement (PR25543)

This is a fix for PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

The idea is to take the existing fold of:
bit

[InstCombine] fold trunc ([lshr] (bitcast vector) ) --> extractelement (PR25543)

This is a fix for PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

The idea is to take the existing fold of:
bitcast ( trunc ( lshr ( bitcast X))) --> extractelement (bitcast X)
( http://reviews.llvm.org/rL112232 )

And break it into less specific transforms so we'll catch more cases such as
the example in the bug report:
bitcast ( trunc ( lshr ( bitcast X))) -->
bitcast ( extractelement (bitcast X)) -->
extractelement (bitcast X)

Enabling patches for this change:
http://reviews.llvm.org/rL255399 (combine bitcasts)
http://reviews.llvm.org/rL255433 (canonicalize extractelement(bitcast X))

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

llvm-svn: 255504

show more ...

[InstCombine] canonicalize (bitcast (extractelement X)) --> (extractelement(bitcast X))

This change was discussed in D15392. It allows us to remove the fold that was added
in:
http://reviews.llvm.or

[InstCombine] canonicalize (bitcast (extractelement X)) --> (extractelement(bitcast X))

This change was discussed in D15392. It allows us to remove the fold that was added
in:
http://reviews.llvm.org/r255261

...and it will allow us to generalize this fold:
http://reviews.llvm.org/rL112232

while preserving the order of bitcast + extract that it produces and testing shows
is better handled by the backend.

Note that the existing check for "isVectorTy()" wasn't strong enough in general
and specifically because: x86_mmx. It's not a vector, but it's not vectorizable
either. So here we check VectorType::isValidElementType() directly before
proceeding with the transform.

llvm-svn: 255433

show more ...

[InstCombine] fold bitcasts around an extractelement (3rd try)

This is a redo of r255137 (reverted at r255227) which was a redo of
r255124 (reverted at r255126) with a fixed check for a scalar sour

[InstCombine] fold bitcasts around an extractelement (3rd try)

This is a redo of r255137 (reverted at r255227) which was a redo of
r255124 (reverted at r255126) with a fixed check for a scalar source
type and an added test for the failure that caused the revert.

Original commit message:

Example:
bitcast (extractelement (bitcast <2 x float> %X to <2 x i32>), 1) to float
--->
extractelement <2 x float> %X, i32 1

This is part of fixing PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

The next step will be to generalize this fold:
trunc ( lshr ( bitcast X) ) -> extractelement (X)

Ie, I'm hoping to replace the existing transform of:
bitcast ( trunc ( lshr ( bitcast X)))
added by:
http://reviews.llvm.org/rL112232

with 2 less specific transforms to catch the case in the bug report.

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

llvm-svn: 255261

show more ...

Revert r255137.

This commit broke apple's internal bot.

llvm-svn: 255227

[InstCombine] fold bitcasts around an extractelement (2nd try)

This is a redo of r255124 (reverted at r255126) with an added check for a
scalar destination type and an added test for the failure see

[InstCombine] fold bitcasts around an extractelement (2nd try)

This is a redo of r255124 (reverted at r255126) with an added check for a
scalar destination type and an added test for the failure seen in Clang's
test/CodeGen/vector.c. The extra test shows a different missing optimization.

Original commit message:

Example:
bitcast (extractelement (bitcast <2 x float> %X to <2 x i32>), 1) to float
--->
extractelement <2 x float> %X, i32 1

This is part of fixing PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

The next step will be to generalize this fold:
trunc ( lshr ( bitcast X) ) -> extractelement (X)

Ie, I'm hoping to replace the existing transform of:
bitcast ( trunc ( lshr ( bitcast X)))
added by:
http://reviews.llvm.org/rL112232

with 2 less specific transforms to catch the case in the bug report.

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

llvm-svn: 255137

show more ...

Revert "[InstCombine] fold bitcasts around an extractelement"

This reverts commit r255124.

Broke http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/4193/steps/test/

Revert "[InstCombine] fold bitcasts around an extractelement"

This reverts commit r255124.

Broke http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/4193/steps/test/logs/stdio

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255126

show more ...

[InstCombine] fold bitcasts around an extractelement

Example:
bitcast (extractelement (bitcast <2 x float> %X to <2 x i32>), 1) to float
--->
extractelement <2 x float> %X, i32 1

This is pa

[InstCombine] fold bitcasts around an extractelement

Example:
bitcast (extractelement (bitcast <2 x float> %X to <2 x i32>), 1) to float
--->
extractelement <2 x float> %X, i32 1

This is part of fixing PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

The next step will be to generalize this fold:
trunc ( lshr ( bitcast X) ) -> extractelement (X)

Ie, I'm hoping to replace the existing transform of:
bitcast ( trunc ( lshr ( bitcast X)))
added by:
http://reviews.llvm.org/rL112232

with 2 less specific transforms to catch the case in the bug report.

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

llvm-svn: 255124

show more ...

fix typo; NFC

llvm-svn: 253785

[InstCombine] refactor optimizeIntToFloatBitCast() ; NFCI

The logic for handling the pattern without a shift is identical
to the logic for handling the pattern with a shift if you set
the shift amo

[InstCombine] refactor optimizeIntToFloatBitCast() ; NFCI

The logic for handling the pattern without a shift is identical
to the logic for handling the pattern with a shift if you set
the shift amount to zero for the former.

This should make it easier to see that we probably don't even need
optimizeIntToFloatBitCast().

If we call something like foldVecTruncToExtElt() from visitTrunc(),
we'll solve PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543

llvm-svn: 253403

show more ...

fix typos; NFC

llvm-svn: 253359

use local variables; NFCI

llvm-svn: 253356

InstCombine: Remove ilist iterator implicit conversions, NFC

Stop relying on implicit conversions of ilist iterators in
LLVMInstCombine. No functionality change intended.

llvm-svn: 250183

There is a trunc(lshr (zext A), Cst) optimization in InstCombineCasts that
removes cast by performing the lshr on smaller types. However, currently there
is no trunc(lshr (sext A), Cst) variant.
This

There is a trunc(lshr (zext A), Cst) optimization in InstCombineCasts that
removes cast by performing the lshr on smaller types. However, currently there
is no trunc(lshr (sext A), Cst) variant.
This patch add such optimization by transforming trunc(lshr (sext A), Cst)
to ashr A, Cst.

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

llvm-svn: 247271

show more ...

Revert trunc(lshr (sext A), Cst) to ashr A, Cst

This reverts commit r246997, it introduced a regression (PR24763).

llvm-svn: 247180

function names start with a lower case letter; NFC

llvm-svn: 247150

don't repeat function names in comments; NFC

llvm-svn: 247148

There is a trunc(lshr (zext A), Cst) optimization in InstCombineCasts that
removes cast by performing the lshr on smaller types. However, currently there
is no trunc(lshr (sext A), Cst) variant.
This

There is a trunc(lshr (zext A), Cst) optimization in InstCombineCasts that
removes cast by performing the lshr on smaller types. However, currently there
is no trunc(lshr (sext A), Cst) variant.
This patch add such optimization by transforming trunc(lshr (sext A), Cst)
to ashr A, Cst.

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

llvm-svn: 246997

show more ...

Add support for floating-point minnum and maxnum

The select pattern recognition in ValueTracking (as used by InstCombine
and SelectionDAGBuilder) only knew about integer patterns. This teaches
it ab

Add support for floating-point minnum and maxnum

The select pattern recognition in ValueTracking (as used by InstCombine
and SelectionDAGBuilder) only knew about integer patterns. This teaches
it about minimum and maximum operations.

matchSelectPattern() has been extended to return a struct containing the
existing Flavor and a new enum defining the pattern's behavior when
given one NaN operand.

C minnum() is defined to return the non-NaN operand in this case, but
the idiomatic C "a < b ? a : b" would return the NaN operand.

ARM and AArch64 at least have different instructions for these different cases.

llvm-svn: 244580

show more ...

Reapply r237539 with a fix for the Chromium build.

Make sure if we're truncating a constant that would then be sign extended
that the sign extension of the truncated constant is the same as the
orig

Reapply r237539 with a fix for the Chromium build.

Make sure if we're truncating a constant that would then be sign extended
that the sign extension of the truncated constant is the same as the
original constant.

> Canonicalize min/max expressions correctly.
>
> This patch introduces a canonical form for min/max idioms where one operand
> is extended or truncated. This often happens when the other operand is a
> constant. For example:
>
> %1 = icmp slt i32 %a, i32 0
> %2 = sext i32 %a to i64
> %3 = select i1 %1, i64 %2, i64 0
>
> Would now be canonicalized into:
>
> %1 = icmp slt i32 %a, i32 0
> %2 = select i1 %1, i32 %a, i32 0
> %3 = sext i32 %2 to i64
>
> This builds upon a patch posted by David Majenemer
> (https://www.marc.info/?l=llvm-commits&m=143008038714141&w=2). That pass
> passively stopped instcombine from ruining canonical patterns. This
> patch additionally actively makes instcombine canonicalize too.
>
> Canonicalization of expressions involving a change in type from int->fp
> or fp->int are not yet implemented.

llvm-svn: 237821

show more ...