| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28479
llvm-svn: 291486
|
|
|
|
|
|
|
|
| |
fabs(x * x) is not generally safe to assume x is positive if x is a NaN.
This is also less general than it could be, so this will be replaced
with a transformation on the intrinsic.
llvm-svn: 291359
|
|
|
|
|
|
|
| |
This creates non-linear behavior in the inliner (see more details in
r289755's commit thread).
llvm-svn: 290086
|
|
|
|
| |
llvm-svn: 289911
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D14590
llvm-svn: 289894
|
|
|
|
|
|
|
|
| |
Lowering to llvm.cttz() will result in constant folding anyway
if the argument to ffs is a constant. Pointed out by Eli for
fls() in D14590.
llvm-svn: 289888
|
|
|
|
|
|
|
|
|
| |
After r289755, the AssumptionCache is no longer needed. Variables affected by
assumptions are now found by using the new operand-bundle-based scheme. This
new scheme is more computationally efficient, and also we need much less
code...
llvm-svn: 289756
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
|
|
|
|
|
|
|
|
|
|
| |
Teach SimplifyLibcalls that in can treat functions annotated with
apcs, aapcs or aapcs_vfp like normal C functions if they only take
and return integer or pointer values, and the target is not iOS.
Differential Revision: https://reviews.llvm.org/D24453
llvm-svn: 281322
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278417
|
|
|
|
|
|
|
|
| |
Hal pointed out that the semantic of our intrinsic and the libc
call are slightly different. Add a comment while I'm here to
explain why we can't emit an intrinsic. Thanks Hal!
llvm-svn: 278200
|
|
|
|
| |
llvm-svn: 277972
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22104
llvm-svn: 277963
|
|
|
|
|
|
| |
moved the optimise for size check inside function optimizeFPuts.
llvm-svn: 274758
|
|
|
|
|
|
| |
because fwrite requires more arguments and thus extra MOVs are required.
llvm-svn: 274753
|
|
|
|
| |
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
|