|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | exp{,2}()
Fix the issue of duplicating the call to `exp{,2}()` when it's nested in
`pow()`, as exposed by rL340462.
Differential revision: https://reviews.llvm.org/D51194
llvm-svn: 340784 | 
| | 
| 
| 
| | llvm-svn: 340476 | 
| | 
| 
| 
| 
| 
| 
| | Refactor all cases dealing with `exp{,2,10}()` into one function in
preparation for D49273.  Otherwise, NFC.
llvm-svn: 340061 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This is a follow-up suggested with rL339604.
For tan(), we don't have a corresponding LLVM 
intrinsic -- unlike sin/cos -- so this is the 
only way/place that we can do this fold currently.
llvm-svn: 339958 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Expand the number of cases when `pow(x, 0.5)` is simplified into `sqrt(x)`
by considering the math semantics with more granularity.
Differential revision: https://reviews.llvm.org/D50036
llvm-svn: 339887 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | (retry r339608)
Even though this code is below a function called optimizeFloatingPointLibCall(),
we apparently can't guarantee that we're dealing with FPMathOperators, so bail
out immediately if that's not true.
llvm-svn: 339618 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | reflection folds
Can't set the builder flags without knowing this is an FPMathOperator. I'll add a test
for that and try again.
llvm-svn: 339609 | 
| | 
| 
| 
| | llvm-svn: 339608 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This is a very partial fix for the reported problem. I suspect
we do not get this fold in most motivating cases because most of
the time, the libcall would have been replaced by an intrinsic,
and that optimization is handled elsewhere...but maybe it should
be handled here?
llvm-svn: 339604 | 
| | 
| 
| 
| | llvm-svn: 339588 | 
| | 
| 
| 
| 
| 
| 
| 
| | Also consider vector constants when simplifying `pow()`.
Differential revision: https://reviews.llvm.org/D50035
llvm-svn: 339578 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Motivation examples:
int strcmp_memcmp() {
    char buf[12];
    return strcmp(buf, "key") == 0;
}
int strcmp_memcmp2() {
    char buf[12];
    return strcmp(buf, "key") != 0;
}
int strncmp_memcmp() {
    char buf[12];
    return strncmp(buf, "key", 3) == 0;
}
can be turned to memcmp.
See test file for more cases.
Reviewers: efriedma
Reviewed By: efriedma
Subscribers: spatel, llvm-commits
Differential Revision: https://reviews.llvm.org/D50233
llvm-svn: 339410 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Properly shrink `pow()` to `powf()` as a binary function and, when no other
simplification applies, do not discard it.
Differential revision: https://reviews.llvm.org/D50113
llvm-svn: 339046 | 
| | 
| 
| 
| 
| 
| 
| | Merge the helper functions for shrinking unary and binary functions into a
single one, while keeping all their functionality.  Otherwise, NFC.
llvm-svn: 338905 | 
| | 
| 
| 
| | llvm-svn: 338730 | 
| | 
| 
| 
| 
| 
| | Reword comments and minor code reformatting.
llvm-svn: 338446 | 
| | 
| 
| 
| 
| 
| | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338293 | 
| | 
| 
| 
| 
| 
| | Use more meaningful variable names.  Mostly NFC.
llvm-svn: 338266 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Review feedback from r328165. Split out just the one function from the
file that's used by Analysis. (As chandlerc pointed out, the original
change only moved the header and not the implementation anyway - which
was fine for the one function that was used (since it's a
template/inlined in the header) but not in general)
llvm-svn: 333954 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
* Use "find('%')" instead of loop to find '%' char (we already uses find('%') in optimizePrintFString..)
* Convert getParent() chains to getModule()/getFunction()
Reviewers: lebedev.ri, spatel
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47397
llvm-svn: 333668 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Also, produce the canonical IR abs (s<0) to be more efficient. 
This is the libcall equivalent of the clang builtin change from:
rL333038
Pasting from that commit message:
The stdlib functions are defined in section 7.20.6.1 of the C standard with:
"If the result cannot be represented, the behavior is undefined."
That lets us mark the negation with 'nsw' because "sub i32 0, INT_MIN" would
be UB/poison.
llvm-svn: 333042 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: Previous patch does not care if a value is changed between calloc and strlen. This needs to be removed from InstCombine and maybe moved to DSE later after some rework.
Reviewers: efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47218
llvm-svn: 333022 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Example cases:
strlen(calloc(...)) -> 0
Reviewers: efriedma, bkramer
Reviewed By: bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47059
llvm-svn: 332990 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reviewers: spatel, efriedma, majnemer, rja, bkramer
Reviewed By: rja, bkramer
Subscribers: mstorsjo, rja, llvm-commits
Differential Revision: https://reviews.llvm.org/D46285
llvm-svn: 332110 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This reverts commit SVN r331889, which could trigger failed
assertions for cases where the snprintf function is declared
with a vaguely differing signature (e.g. being defined as
static inline), see PR37408.
llvm-svn: 332043 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reviewers: spatel, efriedma, majnemer, rja, bkramer
Reviewed By: rja, bkramer
Subscribers: rja, llvm-commits
Differential Revision: https://reviews.llvm.org/D46285
llvm-svn: 331889 | 
| | 
| 
| 
| 
| 
| 
| 
| | This reverts commit r331849. It miscompiles
snprintf(buf, sizeof(buf), "%s", "any constant string); into
memcpy(buf, "%s", sizeof("any constant string"));
llvm-svn: 331866 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reviewers: spatel, efriedma, majnemer, rja
Reviewed By: rja
Subscribers: rja, llvm-commits
Differential Revision: https://reviews.llvm.org/D46285
llvm-svn: 331849 | 
| | 
| 
| 
| 
| 
| | This reverts r331002 due to sanitizer bot breakage.
llvm-svn: 331011 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer
Subscribers: lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 331002 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reviewers: spatel, lebedev.ri, xbolva00, efriedma
Reviewed By: xbolva00, efriedma
Subscribers: efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D45418
llvm-svn: 330860 | 
| | 
| 
| 
| 
| 
| 
| 
| | Patch by Dávid Bolvanský!
Differential Revision: https://reviews.llvm.org/D45413
llvm-svn: 330259 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering.
Transforms depends on Transforms/Utils, not the other way around. So
remove the header and the "createStripGCRelocatesPass" function
declaration (& definition) that is unused and motivated this dependency.
Move Transforms/Utils/Local.h into Analysis because it's used by
Analysis/MemoryBuiltins.cpp.
llvm-svn: 328165 | 
| | 
| 
| 
| 
| 
| | match this file. NFC
llvm-svn: 326475 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | intrinsics (NFC)
Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
SimplifyLibCalls pass to cease using the old IRBuilder createMemCpy/createMemMove
single-alignment APIs in favour of the new API that allows setting source and destination
alignments independently.
Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, r3L24148 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
   http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
   http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
llvm-svn: 324273 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: This patch enables folding sin(x) / cos(x) -> tan(x), cos(x) / sin(x) -> 1 / tan(x) under -ffast-math flag
Reviewers: hfinkel, spatel
Reviewed By: spatel
Subscribers: andrew.w.kaylor, efriedma, scanon, llvm-commits
Differential Revision: https://reviews.llvm.org/D41286
llvm-svn: 322255 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | When unsafe algerbra is allowed calls to cabs(r) can be replaced by:
  sqrt(creal(r)*creal(r) + cimag(r)*cimag(r))
Patch by Paul Walker, thanks!
Differential Revision: https://reviews.llvm.org/D40069
llvm-svn: 320901 | 
| | 
| 
| 
| 
| 
| 
| | Follow-up for a bug that's similar to:
https://bugs.llvm.org/show_bug.cgi?id=35601
llvm-svn: 320312 | 
| | 
| 
| 
| 
| 
| 
| | This should fix the larger problem with sqrt shown in:
https://bugs.llvm.org/show_bug.cgi?id=35601
llvm-svn: 320310 | 
| | 
| 
| 
| | llvm-svn: 318629 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | As the first test shows, we could transform an llvm intrinsic which never sets errno 
into a libcall which could set errno (even though it's marked readnone?), so that's 
not ideal.
It's possible that we can also transform a libcall which could set errno to an
intrinsic given the fast-math-flags constraint, but that's deferred to determine
exactly which set of FMF are needed.
Differential Revision: https://reviews.llvm.org/D40150
llvm-svn: 318628 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | fast-math-flag
As discussed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html
and again more recently:
http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html
...this is a step in cleaning up our fast-math-flags implementation in IR to better match
the capabilities of both clang's user-visible flags and the backend's flags for SDNode.
As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 
'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic 
reassociation - 'AllowReassoc'.
We're also adding a bit to allow approximations for library functions called 'ApproxFunc' 
(this was initially proposed as 'libm' or similar).
...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did 
look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), 
but that's apparently already used for other purposes. Also, I don't think we can just 
add a field to FPMathOperator because Operator is not intended to be instantiated. 
We'll defer movement of FMF to another day.
We keep the 'fast' keyword. I thought about removing that, but seeing IR like this:
%f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2
...made me think we want to keep the shortcut synonym.
Finally, this change is binary incompatible with existing IR as seen in the 
compatibility tests. This statement:
"Newer releases can ignore features from older releases, but they cannot miscompile 
them. For example, if nsw is ever replaced with something else, dropping it would be 
a valid way to upgrade the IR." 
( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility )
...provides the flexibility we want to make this change without requiring a new IR 
version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will 
fail to optimize some previously 'fast' code because it's no longer recognized as 
'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'.
Note: an inter-dependent clang commit to use the new API name should closely follow 
commit.
Differential Revision: https://reviews.llvm.org/D39304
llvm-svn: 317488 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | parameterized emit() calls
Summary: This is not functional change to adopt new emit() API added in r313691.
Reviewed By: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38285
llvm-svn: 315476 | 
| | 
| 
| 
| 
| 
| 
| | Sync it up with the name of the class actually defined here.  This has been
bothering me for a while...
llvm-svn: 315249 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Usually the frontend communicates the size of wchar_t via metadata and
we can optimize wcslen (and possibly other calls in the future). In
cases without the wchar_size metadata we would previously try to guess
the correct size based on the target triple; however this is fragile to
keep up to date and may miss users manually changing the size via flags.
Better be safe and stop guessing and optimizing if the frontend didn't
communicate the size.
Differential Revision: https://reviews.llvm.org/D38106
llvm-svn: 314185 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The 1st try was reverted because it could inf-loop by creating a dead instruction.
Fixed that to not happen and added a test case to verify.
Original commit message:
Try to fold:
memcmp(X, C, ConstantLength) == 0 --> load X == *C
Without this change, we're unnecessarily checking the alignment of the constant data,
so we miss the transform in the first 2 tests in the patch.
I noted this shortcoming of LibCallSimpifier in one of the recent CGP memcmp expansion
patches. This doesn't help the example in:
https://bugs.llvm.org/show_bug.cgi?id=34032#c13
...directly, but it's worth short-circuiting more of these simple cases since we're
already trying to do that.
The benefit of transforming to load+cmp is that existing IR analysis/transforms may
further simplify that code. For example, if the load of the variable is common to
multiple memcmp calls, CSE can remove the duplicate instructions.
Differential Revision: https://reviews.llvm.org/D36922
llvm-svn: 311366 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | arguments
We're getting lots of compile-timeout bot failures like:
http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/7119
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux
llvm-svn: 311340 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Try to fold:
memcmp(X, C, ConstantLength) == 0 --> load X == *C
Without this change, we're unnecessarily checking the alignment of the constant data, 
so we miss the transform in the first 2 tests in the patch.
I noted this shortcoming of LibCallSimpifier in one of the recent CGP memcmp expansion 
patches. This doesn't help the example in:
https://bugs.llvm.org/show_bug.cgi?id=34032#c13
...directly, but it's worth short-circuiting more of these simple cases since we're 
already trying to do that.
The benefit of transforming to load+cmp is that existing IR analysis/transforms may
further simplify that code. For example, if the load of the variable is common to 
multiple memcmp calls, CSE can remove the duplicate instructions.
Differential Revision: https://reviews.llvm.org/D36922
llvm-svn: 311333 | 
| | 
| 
| 
| 
| 
| | Differential Revision: https://reviews.llvm.org/D34163
llvm-svn: 310885 |