| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
'make srpm' or 'ninja srpm' will tar up the current source code and then
build a source RPM package.
By default it will use the llvm.spec file to generate the source RPM,
but you can specify your own custom spec file with the
LLVM_SRPM_USER_BINARY_SPECFILE option. CMake will perform variable
substitution on your custom specfile, so you can reference CMake
variables in it. For example:
Version: @LLVM_RPM_SPEC_VERSION@
Note that everything in the source directory will be included in the
tarball so if you have a clang check out in tools/clang, then all
the clang source will end up in the tarball to. It is recommended
to only use this build target with a clean source tree.
Reviewers: beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30093
llvm-svn: 297007
|
|
|
|
|
|
| |
This reverts commit r297004; it was causing buildbots to fail.
llvm-svn: 297006
|
|
|
|
|
|
|
|
|
|
| |
paths on MingW.
Patch by Mateusz Mikuła.
Differential Revision: https://reviews.llvm.org/D29464
llvm-svn: 297005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I've added a test case that (without the fix) triggers the assertion,
which happens when a move happens in an implicitly called conversion
operator.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D30569
llvm-svn: 297004
|
|
|
|
|
|
|
|
|
|
|
|
| |
rL297000 forgot to include code for three architectures that appeared
since I wrote the first version. This gives them the same treatment as ARMs
have for now - write stubs and wait for someone to actually implement it.
Patched by pelikan (Martin Pelikán)!
Differential Revision: https://reviews.llvm.org/D30634
llvm-svn: 297003
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes a crash caused by r296811 by truncating the input of the STBRX node
when the bswap is wider than i32.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32140
Differential Revision: https://reviews.llvm.org/D30615
llvm-svn: 297001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Functions with the LOG_ARGS_ENTRY sled kind at their beginning will be handled
in a way to (optionally) pass their first call argument to your logging handler.
For practical and performance reasons, only the first argument is supported, and
only up to 64 bits.
Reviewers: javed.absar, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29703
llvm-svn: 297000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Functions with the "xray_log_args" attribute will tell LLVM to emit a special
XRay sled for compiler-rt to copy any call arguments to your logging handler.
Reviewers: dberris
Reviewed By: dberris
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29704
llvm-svn: 296999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Functions with the "xray-log-args" attribute will have a special XRay sled kind
emitted, for compiler-rt to copy any call arguments to your logging handler.
For practical and performance reasons, only the first argument is supported, and
only up to 64 bits.
Reviewers: dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29702
llvm-svn: 296998
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocation from temporary objects
Summary:
This makes operator~ take the APInt by value so if it came from a temporary APInt the move constructor will get invoked and it will be able to reuse the memory allocation from the temporary.
This is similar to what was already done for 2s complement negation.
Reviewers: hans, davide, RKSimon
Reviewed By: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30614
llvm-svn: 296997
|
|
|
|
|
|
|
|
|
|
| |
UBSan's nonnull argument check applies when a parameter has the
"nonnull" attribute. The check currently works for FunctionDecls, but
not for ObjCMethodDecls. This patch extends the check to work for ObjC.
Differential Revision: https://reviews.llvm.org/D30599
llvm-svn: 296996
|
|
|
|
|
|
| |
They aren't used in tree and using the overloaded operators has more optimization opportunities.
llvm-svn: 296995
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r296992 made ScalarEvolution's CompareValueComplexity less aggressive,
and that broke the polly test being fixed in this change. This change
explicitly bumps CompareValueComplexity in said test case to make it
pass.
Can someone from the polly team please can give me an idea on if this
case is important enough to have
scalar-evolution-max-value-compare-depth be 3 by default?
llvm-svn: 296994
|
|
|
|
|
|
|
|
| |
corresponding operator overload.
I plan to enhance the operator overloads to handle rvalues and these methods would not longer be optimal to use.
llvm-svn: 296993
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR32142.
r287232 accidentally increased the recursion threshold for
CompareValueComplexity from 2 to 32. This change reverses that change
by introducing a separate flag for CompareValueComplexity's threshold.
llvm-svn: 296992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While porting libunwind over to CloudABI for ARMv6, I observed that this
source file doesn't build, as it depends on dl_unwind_find_exidx(),
which CloudABI's C library was lacking. After I added that function, I
still needed to patch up libunwind to define _Unwind_Ptr.
Taking a step back, I wonder why we need to make use of this function
anyway. The unwinder already has some nice code to use dl_iterate_phdr()
to scan for a PT_GNU_EH_FRAME header. The dl_unwind_find_exidx() does
the same thing, except matching PT_ARM_EXIDX instead. We could also do
that ourselves.
This change gets rid of the dl_unwind_find_exidx() call and extends the
dl_iterate_phdr() loop. This approach has the advantage of getting rid
of some of those OS-specific #ifdefs. This now means that if an
operating system only provides dl_iterate_phdr(), it gets support for
unwinding on all architectures. There is no need to add more stuff, just
to get ARMv6 support.
This change is identical to r295944, except that it now adds the
necessary code to do bounds checking on PT_LOAD. The previous version of
this change lacked this, which didn't cause any problems on CloudABI,
but did break the Linux build bots. This is why I reverted it in
r295948.
Differential Revision: https://reviews.llvm.org/D30306
llvm-svn: 296991
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
They aren't used anywhere in tree and its preferable to use the &, |, ^, or ~ operators.
With my patch to add rvalue reference support to &, |, ^ operators it also becomes less performant to use these functions.
Reviewers: RKSimon, davide, hans
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30613
llvm-svn: 296990
|
|
|
|
|
|
| |
Found by fuzz testing after rL296985 landed
llvm-svn: 296989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While working on improvements to the region info analysis, this test case caused
an incorrect region 1 => 2 to be detected. It is incorrect because entry has an
outgoing edge to 3. This is interesting because 1 dom 2 and 2 pdom 1, which
should have been enough to prevent incoming forward edges into the region and
outgoing forward edges from the region.
Reviewers: grosser
Subscribers: llvm-commits
Contributed-by: Nandini Singhal <cs15mtech01004@iith.ac.in>
Differential Revision: https://reviews.llvm.org/D30603
llvm-svn: 296988
|
|
|
|
|
|
|
|
| |
X86ISelLowering.cpp:26506:36: error: enumeral mismatch in conditional
expression: 'llvm::X86ISD::NodeType' vs 'llvm::ISD::NodeType'
[-Werror=enum-compare]
llvm-svn: 296986
|
|
|
|
|
|
|
|
|
|
|
|
| |
As described on PR31712, we miss a variety of legalization combines because we lower these to X86ISD::VSEXT/VZEXT despite them having the same functionality. This patch makes 128-bit (SSE41) SIGN/ZERO_EXTEND_VECTOR_IN_REG ops legal, adds the necessary tablegen plumbing and uses a helper 'getExtendInVec' to decide when to use SIGN/ZERO_EXTEND_VECTOR_IN_REG or VSEXT/VZEXT.
We're missing a couple of shuffle combines that will be added in a future patch for review.
Later patches can then support the AVX2 cases as a mixture of SIGN/ZERO_EXTEND and SIGN/ZERO_EXTEND_VECTOR_IN_REG, and then finally deal with the AVX512 cases.
Differential Revision: https://reviews.llvm.org/D30549
llvm-svn: 296985
|
|
|
|
| |
llvm-svn: 296984
|
|
|
|
|
|
| |
I'm looking to improve operator| to support rvalue references and may remove APInt::Or.
llvm-svn: 296982
|
|
|
|
|
|
|
|
| |
APInt and calling APInt::Or. NFC
This is more efficient by itself. But this is prep for a future patch that may remove APInt::Or while making operator| support rvalue references similar to add/sub.
llvm-svn: 296981
|
|
|
|
|
|
| |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625
llvm-svn: 296980
|
|
|
|
|
|
|
|
|
|
| |
easily extend the aggregate-builder API. Stupid missing language
features.
Also add APIs for constructing a relative reference and computing
the offset of a position from the start of the initializer.
llvm-svn: 296979
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The larger goal is to move the ADC/SBB transforms currently in
combineX86SetCC() to combineAddOrSubToADCOrSBB() because we're
creating ADC/SBB in lots of places where we shouldn't.
This was intended to be an NFC change, but avx-512 has something
strange going on. It doesn't seem like any of the affected tests
should really be using SET+TEST or ADC; a simple ADD could replace
several instructions. But that's another bug...
llvm-svn: 296978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
select Cond, C +/- 1, C --> add(ext Cond), C -- with a target hook.
This is part of the ongoing process to obsolete D24480. The motivation is to
canonicalize to select IR in InstCombine whenever possible, so we need to have a way to
undo that easily in codegen.
PowerPC is an obvious winner for this kind of transform because it has fast and complete
bit-twiddling abilities but generally lousy conditional execution perf (although this might
have changed in recent implementations).
x86 also sees some wins, but the effect is limited because these transforms already mostly
exist in its target-specific combineSelectOfTwoConstants(). The fact that we see any x86
changes just shows that that code is a mess of special-case holes. We may be able to remove
some of that logic now.
My guess is that other targets will want to enable this hook for most cases. The likely
follow-ups would be to add value type and/or the constants themselves as parameters for the
hook. As the tests in select_const.ll show, we can transform any select-of-constants to
math/logic, but the general transform for any 2 constants needs one more instruction
(multiply or 'and').
ARM is one target that I think may not want this for most cases. I see infinite loops there
because it wants to use selects to enable conditionally executed instructions.
Differential Revision: https://reviews.llvm.org/D30537
llvm-svn: 296977
|
|
|
|
| |
llvm-svn: 296976
|
|
|
|
|
|
|
|
|
|
|
| |
declarations
Report the typedef as reference, and desugar it to report the underlying class as an
implicit 'base' reference.
Reporting the underlying base class for 'base' relations matches the ObjC handling and
leads to a simpler model.
llvm-svn: 296975
|
|
|
|
|
|
|
|
|
| |
declarations
- Report the typedef reference occurrence
- Mark super or protocol references as 'implicit' when they come from a typedef.
llvm-svn: 296974
|
|
|
|
|
|
|
|
| |
Do not include <sys/user.h> on NetBSD. It's dead file and will be removed.
No need to include <sys/sysctl.h> in this code context on NetBSD.
llvm-svn: 296973
|
|
|
|
| |
llvm-svn: 296972
|
|
|
|
| |
llvm-svn: 296971
|
|
|
|
|
|
|
| |
By patch Peter Goldsborough on https://github.com/llvm-mirror/clang-tools-extra/pull/14
See https://github.com/llvm-mirror/clang-tools-extra/blob/2cd835ee5bcd6c4944d7e30826668ec38db40b38/clang-tidy/modernize/UseNullptrCheck.cpp#L466
llvm-svn: 296970
|
|
|
|
|
|
| |
https://github.com/llvm-mirror/llvm/pull/23
llvm-svn: 296969
|
|
|
|
|
|
| |
By patch zoren here: https://github.com/llvm-mirror/llvm/pull/20
llvm-svn: 296968
|
|
|
|
|
|
| |
https://github.com/llvm-mirror/llvm/pull/6
llvm-svn: 296967
|
|
|
|
|
|
|
|
| |
Long ago (2010 according to svn blame), combineShuffle probably needed to prevent the accidental creation of illegal i64 types but there doesn't appear to be any combines that can cause this any more as they all have their own legality checks.
Differential Revision: https://reviews.llvm.org/D30213
llvm-svn: 296966
|
|
|
|
| |
llvm-svn: 296965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When replacing a SDValue, we should remove the replaced value from
SoftenedFloats (and possibly the other maps as well?).
When we revisit a Node because it needs analyzing again, we have to
remove all result values from SoftenedFloats (and possibly other maps?).
This fixes the fp128 test failures with expensive checks for X86.
I think we probably should also remove the values from the other maps
(PromotedIntegers and so on), let me know what you think.
Reviewers: baldrick, bogner, davidxl, ab, arsenm, pirama, chh, RKSimon
Reviewed By: chh
Subscribers: danalbert, wdng, srhines, hfinkel, sepavloff, llvm-commits
Differential Revision: https://reviews.llvm.org/D29265
llvm-svn: 296964
|
|
|
|
| |
llvm-svn: 296963
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D27004
From: Evgeny Stupachenko <evstupac@gmail.com>
llvm-svn: 296962
|
|
|
|
| |
llvm-svn: 296961
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fully reformats fallback_malloc.cpp. Previously the test
was a mess of different styles and indentations. This made it very
hard to work in and read. Therefore I felt it was best to re-format
the whole thing.
Unfortuantly this means some history will be lost, but hopefully
much of it will still be accessible after ignoring whitespace changes.
llvm-svn: 296960
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D29862
From: Evgeny Stupachenko <evstupac@gmail.com>
llvm-svn: 296959
|
|
|
|
| |
llvm-svn: 296958
|
|
|
|
| |
llvm-svn: 296957
|
|
|
|
|
|
|
|
| |
If the QualType is null, calling ASTContext::getCanonicalType on it will lead
to an assert. This was found while testing a new use for Stmt::Profile, so
there is no test case for this.
llvm-svn: 296956
|
|
|
|
| |
llvm-svn: 296955
|