1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 04:32:44 +01:00
Commit Graph

26 Commits

Author SHA1 Message Date
Vitaly Buka
efa8f57b0d isBytewiseValue checks ConstantVector element by element
Summary: Vector of the same value with few undefs will sill be considered "Bytewise"

Reviewers: eugenis, pcc, jfb

Reviewed By: jfb

Subscribers: dexonsmith, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 365971
2019-07-12 22:37:55 +00:00
Vitaly Buka
66c24fb668 Return Undef from isBytewiseValue for empty arrays or structs
Reviewers: pcc, eugenis

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 365864
2019-07-12 02:23:07 +00:00
Vitaly Buka
b875fd735d Handle IntToPtr in isBytewiseValue
Summary:
This helps with more efficient use of memset for pattern initialization

From @pcc prototype for -ftrivial-auto-var-init=pattern optimizations

Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results with default linker options)
```
                   master           patch      diff
Os           8.238864e+05    8.238864e+05       0.0
O3           1.054797e+06    1.054797e+06       0.0
Os zero      8.292384e+05    8.292384e+05       0.0
O3 zero      1.062626e+06    1.062626e+06       0.0
Os pattern   8.579712e+05    8.338048e+05 -0.030299
O3 pattern   1.090502e+06    1.067574e+06 -0.020481
```

Zero vs Pattern on master
```
               zero       pattern      diff
Os     8.292384e+05  8.579712e+05  0.036578
O3     1.062626e+06  1.090502e+06  0.025124
```

Zero vs Pattern with the patch
```
               zero       pattern      diff
Os     8.292384e+05  8.338048e+05  0.003333
O3     1.062626e+06  1.067574e+06  0.003193
```

Reviewers: pcc, eugenis

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 365858
2019-07-12 01:42:03 +00:00
Mikael Holmen
bca59d7f71 [test] Silence gcc 7.4 warning [NFC]
Without this gcc 7.4.0 complains with
 ../unittests/Analysis/ValueTrackingTest.cpp:937:66: error: ISO C++11 requires at least one argument for the "..." in a variadic macro [-Werror]
                          ::testing::ValuesIn(IsBytewiseValueTests));
                                                                   ^

llvm-svn: 365738
2019-07-11 07:07:23 +00:00
Vitaly Buka
1998d38e13 Add IsBytewiseValue unit test
Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 365710
2019-07-10 22:56:15 +00:00
Johannes Doerfert
6275dfc50e Use "willreturn" in isGuaranteedToTransferExecutionToSuccessor
The `willreturn` function attribute guarantees that a function call will
come back to the call site if the call is also known not to throw.
Therefore, this attribute can be used in
`isGuaranteedToTransferExecutionToSuccessor`.

Patch by Hideto Ueno (@uenoku)

Reviewers: jdoerfert, sstefan1

Reviewed By: jdoerfert

Subscribers: hiraditya, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 364580
2019-06-27 19:29:48 +00:00
Nikita Popov
8b6244e618 [ValueTracking] Known bits support for unsigned saturating add/sub
We have two sources of known bits:

1. For adds leading ones of either operand are preserved. For sub
leading zeros of LHS and leading ones of RHS become leading zeros in
the result.

2. The saturating math is a select between add/sub and an all-ones/
zero value. As such we can carry out the add/sub known bits
calculation, and only preseve the known one/zero bits respectively.

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

llvm-svn: 355223
2019-03-01 20:07:04 +00:00
Chandler Carruth
ae65e281f3 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Nikita Popov
bb7c898cb7 [ValueTracking] Support funnel shifts in computeKnownBits()
If the shift amount is known, we can determine the known bits of the
output based on the known bits of two inputs.

This is essentially the same functionality as implemented in D54869,
but for ValueTracking rather than InstCombine SimplifyDemandedBits.

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

llvm-svn: 348091
2018-12-02 14:14:11 +00:00
Nikita Popov
3a2addb4a0 [ValueTracking] Make unit tests easier to write; NFC
Generalize the existing MatchSelectPatternTest class to also work
with other types of tests. This reduces the amount of boilerplate
necessary to write ValueTracking tests in general, and computeKnownBits
tests in particular.

The inherited convention is that the function must be @test and the
tested instruction %A.

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

llvm-svn: 348043
2018-11-30 22:22:30 +00:00
Sanjay Patel
7a0d37b0c0 [ValueTracking] determine sign of 0.0 from select when matching min/max FP
In PR39475:
https://bugs.llvm.org/show_bug.cgi?id=39475
..we may fail to recognize/simplify fabs() in some cases because we do not 
canonicalize fcmp with a -0.0 operand.

Adding that canonicalization can cause regressions on min/max FP tests, so 
that's this patch: for the purpose of determining whether something is min/max, 
let the value returned by the select determine how we treat a 0.0 operand in the fcmp.

This patch doesn't actually change the -0.0 to +0.0. It just changes the analysis, so 
we don't fail to recognize equivalent min/max patterns that only differ in the 
signbit of 0.0.

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

llvm-svn: 346097
2018-11-04 14:28:48 +00:00
Sanjay Patel
72bbb14e2a [ValueTracking] peek through 2-input shuffles in ComputeNumSignBits
This patch gives the IR ComputeNumSignBits the same functionality as the 
DAG version (the code is derived from the existing code).

This an extension of the single input shuffle analysis added with D53659.

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

llvm-svn: 346071
2018-11-03 13:18:55 +00:00
Sanjay Patel
8b1b1e2098 [ValueTracking] add test for non-canonical shuffle; NFC
llvm-svn: 346025
2018-11-02 18:14:24 +00:00
Sanjay Patel
5a1156b72d [ValueTracking] allow non-canonical shuffles when computing signbits
This possibility is noted in D53987 for a different case,
so we need to adjust the existing code.

llvm-svn: 345988
2018-11-02 15:51:47 +00:00
Sanjay Patel
f773950be2 [ValueTracking] add tests for fmin/fmax; NFC
llvm-svn: 345777
2018-10-31 21:11:59 +00:00
Thomas Lively
e649dc137e [NFC] Rename minnan and maxnan to minimum and maximum
Summary:
Changes all uses of minnan/maxnan to minimum/maximum
globally. These names emphasize that the semantic difference between
these operations is more than just NaN-propagation.

Reviewers: arsenm, aheejin, dschuff, javed.absar

Subscribers: jholewinski, sdardis, wdng, sbc100, jgravelle-google, jrtc27, atanasyan, llvm-commits

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

llvm-svn: 345218
2018-10-24 22:49:55 +00:00
Thomas Lively
4754140dfc [ValueTracking] Allow select patterns to work on FP vectors
Summary:
This CL allows constant vectors of floats to be recognized as non-NaN
and non-zero in select patterns. This change makes
`matchSelectPattern` more powerful generally, but was motivated
specifically because I wanted fminnan and fmaxnan to be created for
vector versions of the scalar patterns they are created for.

Tested with check-all on all targets. A testcase in the WebAssembly
backend that tests the non-nan codepath is in an upcoming CL.

Reviewers: aheejin, dschuff

Subscribers: sunfish, llvm-commits

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

llvm-svn: 343364
2018-09-28 21:36:43 +00:00
Simon Dardis
186f679a98 Infer lowest bits of an integer Multiply when the low bits of the operands are known
When the lowest bits of the operands to an integer multiply are known, the low bits of the result are deducible.
Code to deduce known-zero bottom bits already existed, but this change improves on that by deducing known-ones.

Patch by: Pedro Ferreira

Reviewers: craig.topper, sanjoy, efriedma

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

llvm-svn: 320269
2017-12-09 23:25:57 +00:00
Craig Topper
9f4fbdf31c [ValueTracking] Avoid undefined behavior in unittest by not making a named ArrayRef from a std::initializer_list
One of the ValueTracking unittests creates a named ArrayRef initialized by a std::initializer_list. The underlying array for an std::initializer_list is only guaranteed to have a lifetime as long as the initializer_list object itself. So this can leave the ArrayRef pointing at an array that no long exists.

This fixes this to just create an explicit array instead of an ArrayRef.

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

llvm-svn: 300354
2017-04-14 17:59:19 +00:00
Sanjoy Das
97ea3c33f1 Fix signed-unsigned comparison warning
llvm-svn: 296274
2017-02-25 22:25:48 +00:00
Sanjoy Das
059733f666 [ValueTracking] Don't do an unchecked shift in ComputeNumSignBits
Summary:
Previously we used to return a bogus result, 0, for IR like `ashr %val,
-1`.

I've also added an assert checking that `ComputeNumSignBits` at least
returns 1.  That assert found an already checked in test case where we
were returning a bad result for `ashr %val, -1`.

Fixes PR32045.

Reviewers: spatel, majnemer

Reviewed By: spatel, majnemer

Subscribers: efriedma, mcrosier, llvm-commits

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

llvm-svn: 296273
2017-02-25 20:30:45 +00:00
Sanjoy Das
a2fc5cf9c6 Fix an issue with isGuaranteedToTransferExecutionToSuccessor
I'm not sure if this was intentional, but today
isGuaranteedToTransferExecutionToSuccessor returns true for readonly and
argmemonly calls that may throw.  This commit changes the function to
not implicitly infer nounwind this way.

Even if we eventually specify readonly calls as not throwing,
isGuaranteedToTransferExecutionToSuccessor is not the best place to
infer that.  We should instead teach FunctionAttrs or some other such
pass to tag readonly functions / calls as nounwind instead.

llvm-svn: 290794
2016-12-31 22:12:34 +00:00
Mehdi Amini
ea195a382e Remove every uses of getGlobalContext() in LLVM (but the C API)
At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.

This is the first part of http://reviews.llvm.org/D19094

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266379
2016-04-14 21:59:01 +00:00
James Molloy
4012d66e46 [ValueTracking] Minor comment change in test
This test was updated in r246678 - fix a copypasta in a comment noticed post-commit.

llvm-svn: 246679
2015-09-02 17:29:54 +00:00
James Molloy
eacb992ece [ValueTracking] Look through casts when both operands are casts.
We only looked through casts when one operand was a constant. We can also look through casts when both operands are non-constant, but both are in fact the same cast type. For example:

%1 = icmp ult i8 %a, %b
%2 = zext i8 %a to i32
%3 = zext i8 %b to i32
%4 = select i1 %1, i32 %2, i32 %3

llvm-svn: 246678
2015-09-02 17:25:25 +00:00
James Molloy
ecd6525b24 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
2015-08-11 09:12:57 +00:00