| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 268922
|
|
|
|
|
|
|
|
|
| |
I tried to be as close as possible to the strongest check that
existed before; cleaning these up properly is left for future work.
Differential Revision: http://reviews.llvm.org/D19469
llvm-svn: 267758
|
|
|
|
|
|
|
|
|
|
| |
The destination buffer that sprintf uses is restrict qualified, we do
not need to worry about derived pointers referenced via format
specifiers.
This reverts commit r267580.
llvm-svn: 267605
|
|
|
|
|
|
|
|
|
|
| |
sprintf doesn't read or copy the terminating null byte from it's string
operands. sprintf will append it's own after processing all of the
format specifiers.
This fixes PR27526.
llvm-svn: 267580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed some unused headers, replaced some headers with forward class declarations.
Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'
Patch by Eugene Kosov <claprix@yandex.ru>
Differential Revision: http://reviews.llvm.org/D19219
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
|
|
|
|
|
|
|
|
| |
Patch by Li Huang (li1.huang@intel.com)
Differential Revision: http://reviews.llvm.org/D18230
llvm-svn: 266200
|
|
|
|
|
|
|
|
|
|
| |
We already skip optimizations if the return value
of printf() is used, so CI->use_empty() is always
true.
Differential Revision: http://reviews.llvm.org/D18656
llvm-svn: 265253
|
|
|
|
| |
llvm-svn: 264588
|
|
|
|
|
|
|
|
|
|
| |
The sinpi/cospi can be replaced with sincospi to remove unnecessary
computations. However, we need to make sure that the calls are within
the same function!
This fixes PR26993.
llvm-svn: 263875
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a step towards solving PR25892:
https://llvm.org/bugs/show_bug.cgi?id=25892
It won't handle the reported case. As noted by the 'TODO' comments in the patch,
we need to relax the hasOneUse() constraint and also match patterns that include
memset_chk() and the llvm.memset() intrinsic in addition to memset().
Differential Revision: http://reviews.llvm.org/D16337
llvm-svn: 258816
|
|
|
|
| |
llvm-svn: 258455
|
|
|
|
|
|
|
|
|
| |
Use the helper function added in r258428.
The check should really be hoisted to the caller of all of these
optimize* functions, but that's another step.
llvm-svn: 258446
|
|
|
|
| |
llvm-svn: 258445
|
|
|
|
| |
llvm-svn: 258444
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the bug/fix:
https://llvm.org/bugs/show_bug.cgi?id=26211
http://reviews.llvm.org/rL258325
The fmin() test case reveals another bug caused by sloppy
code duplication. It will crash without this patch because
fp128 is a valid floating-point type, but we would think
that we had matched a function that used doubles.
The new helper function can be used to replace similar
checks that are used in several other places in this file.
llvm-svn: 258428
|
|
|
|
| |
llvm-svn: 258416
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case will crash without this patch because the subsequent call to
hasUnsafeAlgebra() assumes that the call instruction is an FPMathOperator
(ie, returns an FP type).
This part of the function signature check was omitted for the sqrt() case,
but seems to be in place for all other transforms.
Before:
http://reviews.llvm.org/rL257400
...we would have needlessly continued execution in optimizeSqrt(), but the
bug was harmless because we'd eventually fail some other check and return
without damage.
This should fix:
https://llvm.org/bugs/show_bug.cgi?id=26211
Differential Revision: http://reviews.llvm.org/D16198
llvm-svn: 258325
|
|
|
|
|
|
|
|
| |
Note: There are no uses of these functions outside of
SimplifyLibCalls, so they could be static functions in
that file.
llvm-svn: 258172
|
|
|
|
|
|
|
| |
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
llvm-svn: 258158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pow(x, [small integer]) calls
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
As with D15937, the intent of the patch is to preserve the current behavior of the transform
except that we use the pow call's 'fast' attribute as a trigger rather than a function-level
attribute.
The TODO comment notes a potential follow-on patch that would propagate FMF to the new
instructions.
Differential Revision: http://reviews.llvm.org/D16122
llvm-svn: 258153
|
|
|
|
|
|
|
|
| |
pow(x, 0.5) calls
Also, propagate the FMF to the newly created sqrt() call.
llvm-svn: 257503
|
|
|
|
| |
llvm-svn: 257496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pow(exp(x)) calls
See also:
http://reviews.llvm.org/rL255555
http://reviews.llvm.org/rL256871
http://reviews.llvm.org/rL256964
http://reviews.llvm.org/rL257400
http://reviews.llvm.org/rL257404
http://reviews.llvm.org/rL257414
llvm-svn: 257491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, add tests to verify that we're checking 'fast' on both calls of each transform pair,
tighten the CHECK lines, and give the tests more meaningful names.
This is a continuation of:
http://reviews.llvm.org/rL255555
http://reviews.llvm.org/rL256871
http://reviews.llvm.org/rL256964
http://reviews.llvm.org/rL257400
http://reviews.llvm.org/rL257404
llvm-svn: 257414
|
|
|
|
|
|
|
| |
Fix the FIXME added with:
http://reviews.llvm.org/rL257400
llvm-svn: 257404
|
|
|
|
| |
llvm-svn: 257401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
The intent of the patch is to preserve the current behavior of the transform except
that we use the sqrt instruction's 'fast' attribute as a trigger rather than the
function-level attribute.
But this raises a bug noted by the new FIXME comment.
In order to do this transform:
sqrt((x * x) * y) ---> fabs(x) * sqrt(y)
...we need all of the sqrt, the first fmul, and the second fmul to be 'fast'.
If any of those ops is strict, we should bail out.
Differential Revision: http://reviews.llvm.org/D15937
llvm-svn: 257400
|
|
|
|
| |
llvm-svn: 256973
|
|
|
|
| |
llvm-svn: 256964
|
|
|
|
|
|
|
|
|
| |
If we replace one call-site with another, be sure to move over any
operand bundles that lingered on the old call-site.
This fixes PR26036.
llvm-svn: 256912
|
|
|
|
| |
llvm-svn: 256884
|
|
|
|
|
|
| |
transforms
llvm-svn: 256871
|
|
|
|
| |
llvm-svn: 256682
|
|
|
|
| |
llvm-svn: 256679
|
|
|
|
| |
llvm-svn: 256676
|
|
|
|
| |
llvm-svn: 256675
|
|
|
|
| |
llvm-svn: 255511
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In order to avoid calling pow function we generate repeated fmul when n is a
positive or negative whole number.
For each exponent we pre-compute Addition Chains in order to minimize the no.
of fmuls.
Refer: http://wwwhomes.uni-bielefeld.de/achim/addition_chain.html
We pre-compute addition chains for exponents upto 32 (which results in a max of
7 fmuls).
For eg:
4 = 2+2
5 = 2+3
6 = 3+3 and so on
Hence,
pow(x, 4.0) ==> y = fmul x, x
x = fmul y, y
ret x
For negative exponents, we simply compute the reciprocal of the final result.
Note: This transformation is only enabled under fast-math.
Patch by Mandeep Singh Grang <mgrang@codeaurora.org>
Reviewers: weimingz, majnemer, escha, davide, scanon, joerg
Subscribers: probinson, escha, llvm-commits
Differential Revision: http://reviews.llvm.org/D13994
llvm-svn: 254776
|
|
|
|
| |
llvm-svn: 254317
|
|
|
|
| |
llvm-svn: 254265
|
|
|
|
| |
llvm-svn: 254264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is enabled only under -ffast-math. There are cases where the
difference between the value computed and the correct value is huge
even for ffast-math, e.g. as Steven pointed out:
x = -1, y = -4
log(pow(-1), 4) = 0
4*log(-1) = NaN
I checked what GCC does and apparently they do the same optimization
(which result in the dramatic difference). Future work might try to
make this (slightly) less worse.
Differential Revision: http://reviews.llvm.org/D14400
llvm-svn: 254263
|
|
|
|
| |
llvm-svn: 254239
|
|
|
|
|
|
|
|
| |
memory read below.
Found by msan!
llvm-svn: 254238
|
|
|
|
| |
llvm-svn: 254193
|
|
|
|
|
|
|
|
| |
be an indirect call.
Fixes the crasher in PR25651 and related crashers using the same pattern.
llvm-svn: 254145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Followed the guidelines in:
http://llvm.org/docs/CodingStandards.html#include-style
However, I noticed that uppercase named headers come before lowercase ones
throughout the codebase. So kept them as is.
Patch by Mandeep Singh Grang <mgrang@codeaurora.org>
Reviewers: majnemer, davide, jmolloy, atrick
Subscribers: sanjoy
Differential Revision: http://reviews.llvm.org/D14939
llvm-svn: 254005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D14302 implements tan(atan(x)) -> x
D14045 implements pow(exp(x), y) -> exp(x*y)
Patch by Mandeep Singh Grang <mgrang@codeaurora.org>
Reviewers: majnemer, davide
Differential Revision: http://reviews.llvm.org/D14882
llvm-svn: 253768
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r253511.
This likely broke the bots in
http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202
http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787
llvm-svn: 253543
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14466
llvm-svn: 253521
|