| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D62077
llvm-svn: 361151
|
|
|
|
| |
llvm-svn: 361076
|
|
|
|
| |
llvm-svn: 361060
|
|
|
|
|
|
|
|
| |
In test/Transforms/InstSimplify/floating-point-arithmetic.ll
Differential Revision: https://reviews.llvm.org/D62069
llvm-svn: 361057
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D61573
llvm-svn: 360053
|
|
|
|
|
|
|
|
| |
The reversion apparently deleted the test/Transforms directory.
Will be re-reverting again.
llvm-svn: 358552
|
|
|
|
|
|
|
|
| |
As it's causing some bot failures (and per request from kbarton).
This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda.
llvm-svn: 358546
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D52765
Reviewers: aheejin, dschuff
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52766
llvm-svn: 344799
|
|
|
|
| |
llvm-svn: 339396
|
|
|
|
| |
llvm-svn: 339176
|
|
|
|
| |
llvm-svn: 339174
|
|
|
|
| |
llvm-svn: 339171
|
|
|
|
|
|
|
|
| |
Instcombine gets some, but not all, of these cases via
it's internal reassociation transforms. It fails in
all cases with vector types.
llvm-svn: 339168
|
|
|
|
| |
llvm-svn: 339144
|
|
|
|
| |
llvm-svn: 339142
|
|
|
|
| |
llvm-svn: 339141
|
|
|
|
| |
llvm-svn: 338719
|
|
|
|
| |
llvm-svn: 338652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fold is repeated/misplaced in instcombine, but I'm
not sure if it's safe to remove that yet because some
other folds appear to be asserting that the transform
has occurred within instcombine itself.
This isn't the best fix for PR37776, but it probably
hides the bug with the given code example:
https://bugs.llvm.org/show_bug.cgi?id=37776
We have another test to demonstrate the more general bug.
llvm-svn: 337127
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't the best fix for PR37776, but it probably
hides the bug with the given code example:
https://bugs.llvm.org/show_bug.cgi?id=37776
We have another test to demonstrate the more general
bug.
llvm-svn: 337126
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This continues the FP constant pattern matching improvements from:
https://reviews.llvm.org/rL327627
https://reviews.llvm.org/rL327339
https://reviews.llvm.org/rL327307
Several integer constant matchers also have this ability. I'm
separating matching of integer/pointer null from FP positive zero
and renaming/commenting to make the functionality clearer.
llvm-svn: 328461
|
|
|
|
| |
llvm-svn: 328455
|
|
|
|
|
|
|
|
|
| |
This is the FP equivalent of D42818. Use it for the few cases in InstSimplify
with -0.0 folds (that's the only current use of m_NegZero()).
Differential Revision: https://reviews.llvm.org/D43792
llvm-svn: 327307
|
|
|
|
| |
llvm-svn: 327287
|
|
|
|
|
|
|
|
|
|
| |
ExtractElement.
This is similar to what's done in computeKnownBits and computeSignBits. Don't do anything fancy just collect information valid for any element.
Differential Revision: https://reviews.llvm.org/D43789
llvm-svn: 326237
|
|
|
|
|
|
| |
vectors; NFC
llvm-svn: 326148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constants.
Summary: This allows vector fabs to be removed in more cases.
Reviewers: spatel, arsenm, RKSimon
Reviewed By: spatel
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43739
llvm-svn: 326138
|
|
|
|
| |
llvm-svn: 326050
|
|
|
|
| |
llvm-svn: 326049
|
|
|
|
|
|
|
|
| |
The InstCombine integer mul test file had tests that belong in InstSimplify
(including fmul tests). Move things to where they belong and auto-generate
complete checks for everything.
llvm-svn: 325037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously we assumed that the result of sqrt(x) always had 0 as its
sign bit. But sqrt(-0) == -0.
Reviewers: hfinkel, efriedma, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28928
llvm-svn: 293115
|
|
|
|
| |
llvm-svn: 291624
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27587
llvm-svn: 289153
|
|
|
|
| |
llvm-svn: 289098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I didn't notice any significant changes in the actual checks here;
all of these tests already used FileCheck, so a script can batch
update them in one shot.
This commit is just to show the value of automating this process:
We have uniform formatting as opposed to a mish-mash of check
structure that changes based on individual prefs and the current
fashion. This makes it simpler to update when we find a bug or
make an enhancement.
llvm-svn: 264457
|
|
|
|
|
|
|
|
| |
are ignored.
Only allow fsub -0.0, (fsub -0.0, X) ==> X without nsz. PR26746.
llvm-svn: 262212
|
|
|
|
|
|
|
|
|
|
| |
With a diabolically crafted test case, we could recurse
through this code and return true instead of false.
The larger engineering crime is the use of magic numbers.
Added FIXME comments for those.
llvm-svn: 230515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functionality change.
This update was done with the following bash script:
find test/Transforms -name "*.ll" | \
while read NAME; do
echo "$NAME"
if ! grep -q "^; *RUN: *llc" $NAME; then
TEMP=`mktemp -t temp`
cp $NAME $TEMP
sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \
while read FUNC; do
sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP
done
mv $TEMP $NAME
fi
done
llvm-svn: 186268
|
|
|
|
| |
llvm-svn: 179277
|
|
which take advantage of fast-math flags. Test cases included.
fsub X, +0 ==> X
fsub X, -0 ==> X, when we know X is not -0
fsub +/-0.0, (fsub -0.0, X) ==> X
fsub nsz +/-0.0, (fsub +/-0.0, X) ==> X
fsub nnan ninf X, X ==> 0.0
fadd nsz X, 0 ==> X
fadd [nnan ninf] X, (fsub [nnan ninf] 0, X) ==> 0
where nnan and ninf have to occur at least once somewhere in this expression
fmul X, 1.0 ==> X
llvm-svn: 169940
|