This reverts commit r297004; it was causing buildbots to fail.

llvm-svn: 297006

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

[APInt] Move operator~ out of line to make it better able to reused memory 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

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

[DAGCombine] Use APInt::operator|(uint64_t) instead of creating a temporary 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

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

- 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

llvm-svn: 296969

By patch zoren here: https://github.com/llvm-mirror/llvm/pull/20

llvm-svn: 296968

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