[APInt] In operator!, handle single word case by comparing VAL to 0 directly and handle multiword case by comparing countLeadingZerosSlowCase() to BitWidth.

We were using operator=(0) which implicitly calls countLeadingZeros but only to compare with 64 to determine if we can compare VAL or pVal[0] to uint64_t. By handling the multiword case with countLeadingZerosSlowCase==BitWidth we can prevent a load of pVal[0] from being inserted inline at each call site. This saves a little bit of code size.

llvm-svn: 301842

NFC

llvm-svn: 301841

These tests do not appear to be Darwin-specific, and this REQUIRES: appears to
be hiding a real bug; this change is just restoring the prior state to get the
buildbots happy again while we investigate. (The system-darwin requirement is
covered by PR32851.)

llvm-svn: 301840

This makes it possible to get stacktrace info when print_stacktrace=1 on
Darwin (where the slow unwinder is not currently supported [1]). This
should not regress any other platforms.

[1] The thread about r300295 has a relatively recent discusion about
this. We should be able to enable the existing slow unwind functionality
for Darwin, but this needs more testing.

Differential Revision: https://reviews.llvm.org/D32517

llvm-svn: 301839

llvm-svn: 301838

llvm-svn: 301837

Patch by Réka Nikolett Kovács!

llvm-svn: 301836

llvm-svn: 301835

Since the shuffle refactor, this is only used during BUILD_VECTOR lowering.

llvm-svn: 301834

Also factored out code.

llvm-svn: 301833

Differential Revision: https://reviews.llvm.org/D32195

llvm-svn: 301832

From Phab D32031.

llvm-svn: 301831

When using linkerscripts we were trying to sort SHF_LINK_ORDER
sections too early. Instead of always doing two runs of
assignAddresses, record the section order in processCommands.

llvm-svn: 301830

A .cur instruction can be identified by checking isCVINew() && mayLoad().

Patch by Colin LeMahieu.

llvm-svn: 301829

Patch by Colin LeMahieu.

llvm-svn: 301828

Patch by Colin LeMahieu.

llvm-svn: 301827

llvm-svn: 301826

llvm-svn: 301825

llvm-svn: 301824

Patch by Colin LeMahieu.

llvm-svn: 301823

Do not spuriously reject constexpr functions that access elements of an array
of unknown bound; this may later become valid once the bound is known. Permit
array-to-pointer decay on such arrays, but disallow pointer arithmetic (since
we do not know whether it will have defined behavior).

The standard is not clear on how this should work, but this seems to be a
decent answer.

Patch by Robert Haberlach!

llvm-svn: 301822

Leaving a directory with a permission 0o100 is inconvenient.
For example, macOS's rm can't remove such directory.

llvm-svn: 301821

llvm-svn: 301820

Otherwise an indeterminate value gets read, causing a bunch of UBSan failures.

llvm-svn: 301819

Per http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

llvm-svn: 301818

This was an omission in r301813.  I had made the supporting changes to
make this happen, but I forgot to actually update the PrevPair
declaration.

llvm-svn: 301817

We may not be able to rewrite indirect branch target, but we also want to take it into
account when folding, i.e. if it and all its successor's predecessors go to the same
destination, we can fold, i.e. no need to thread.

llvm-svn: 301816

llvm-svn: 301815

In cases where an instruction (a call site, say) is RAUW'ed with some
other value (this is possible via the `returned` attribute, for
instance), we want the slot in UnknownInsts to point to the original
Instruction we wanted to track, not the value it got replaced by.

Fixes PR32587.

This relands r301426.

llvm-svn: 301814

This relands r301425.

llvm-svn: 301813

This relands r301424.

llvm-svn: 301812

llvm-svn: 301811

In preparation for introducing writing capabilities for each of
these classes, I would like to adopt a Foo / FooRef naming
convention, where Foo indicates that the class can manipulate and
serialize Foos, and FooRef indicates that it is an immutable view of
an existing Foo.  In other words, Foo is a writer and FooRef is a
reader.  This patch names some existing readers to conform to the
FooRef convention, while offering no functional change.

llvm-svn: 301810

Summary:
This frees up one slot in the HandleBaseKind enum, which I will use
later to add a new kind of value handle.  The size of the
HandleBaseKind enum is important because we store a HandleBaseKind in
the low two bits of a (in the worst case) 4 byte aligned pointer.

Reviewers: davide, chandlerc

Subscribers: mcrosier, llvm-commits

Differential Revision: https://reviews.llvm.org/D32634

llvm-svn: 301809

llvm-svn: 301808

Patch by: Gergely Angeli!

Differential Revision: https://reviews.llvm.org/D31936

llvm-svn: 301807

[SelectionDAG] Use known ones to provide a better bound for the known zeros for CTTZ/CTLZ operations.

This is the SelectionDAG version of D32521. If know where at least one 1 is located in the input to these intrinsics we can place an upper bound on the number of bits needed to represent the count and thus increase the number of known zeros in the output.

I think we can also refine this further for CTTZ_UNDEF/CTLZ_UNDEF by assuming that the answer will never be BitWidth. I've left this out for now because it caused other test failures across multiple targets. Usually because of turning ADD into OR based on this new information.

I'll fix CTPOP in a future patch.

Differential Revision: https://reviews.llvm.org/D32692

llvm-svn: 301806

llvm-svn: 301805

Summary: [JumpThread] Do RAUW in case Cond folds to a constant in the CFG

Reviewers: sanjoy

Reviewed By: sanjoy

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D32407

llvm-svn: 301804

This removes BinaryWithFlagsSDNode, and flags are now all passed by value.

Differential Revision: https://reviews.llvm.org/D32527

llvm-svn: 301803