(And test my commit access. We're working on larger changes here.)

Revert 4334892e "[DAGCombine][ARM] x ==/!= c  ->  (x - c) ==/!= 0  iff '-c' can be folded into the x node."

This broke various Windows builds, see comments on the Phabricator
review.

This also reverts the follow-up 20bf0cf2.

> Summary:
> This fold, helps recover from the rest of the D62266 ARM regressions.
> https://rise4fun.com/Alive/TvpC
>
> Note that while the fold is quite flexible, i've restricted it
> to the single interesting pattern at the moment.
>
> Reviewers: efriedma, craig.topper, spatel, RKSimon, deadalnix
>
> Reviewed By: deadalnix
>
> Subscribers: javed.absar, kristof.beyls, llvm-commits
>
> Tags: #llvm
>
> Differential Revision: https://reviews.llvm.org/D62450

Summary:
So far we rely on the default argument and the fact that we don't call this
inline function in our actual `main.cpp` to make sure that this function can only
be called if LLDB loads this header as a C++ module. This patch just adds
the nodebug attribute as yet another measure to make sure LLDB can't call this
function without the standard module loaded. Note that the test is already
requiring clang for the sysroot setup, so its fine that this is a Clang specific attribute.

Reviewers: friss, labath

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

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

against the latest version of D68233.

Summary:
A certain class of bug (e.g. infloop on an AST worker thread) currently means
clangd never terminates, even if the editor shuts down the protocol and closes
our stdin, and the main thread recognizes that.

Instead, let's wait 60 seconds for threads to finish cleanly, and then crash
if they haven't.

(Obviously, we should still fix these bugs).

Reviewers: kadircet

Subscribers: MaskRay, jkorous, arphaman, jfb, usaxena95, cfe-commits, ilya-biryukov

Tags: #clang

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

I should have updated it in 1f665046
but i didn't even realize those tests were there.

Summary: This is a fix to revision D68839 and rL375023. This patch substitutes POSIX option "-b" for the non-portable GNU option "--strip-trailing-cr".

Reviewers: daltenty, hubert.reinterpretcast

Reviewed By: daltenty

Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, llvm-commits

Tags: #llvm

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

Now that there's SaturatingInst class, this is cleaner.

Summary:
This was suggested in https://reviews.llvm.org/D69277#1717210
In this form (this is what was suggested, right?), the results aren't staggering
(especially since given LVI cross-block focus)
this does catch some things (as per test-suite), but not too much:

| statistic                                        |       old |       new | delta | % change |
| correlated-value-propagation.NumAddNSW           |      4981 |      4982 |     1 |  0.0201% |
| correlated-value-propagation.NumAddNW            |     12125 |     12126 |     1 |  0.0082% |
| correlated-value-propagation.NumCmps             |      1199 |      1202 |     3 |  0.2502% |
| correlated-value-propagation.NumDeadCases        |       112 |       111 |    -1 | -0.8929% |
| correlated-value-propagation.NumMulNSW           |       275 |       278 |     3 |  1.0909% |
| correlated-value-propagation.NumMulNUW           |      1323 |      1326 |     3 |  0.2268% |
| correlated-value-propagation.NumMulNW            |      1598 |      1604 |     6 |  0.3755% |
| correlated-value-propagation.NumNSW              |      7158 |      7167 |     9 |  0.1257% |
| correlated-value-propagation.NumNUW              |     13304 |     13310 |     6 |  0.0451% |
| correlated-value-propagation.NumNW               |     20462 |     20477 |    15 |  0.0733% |
| correlated-value-propagation.NumOverflows        |         4 |         7 |     3 | 75.0000% |
| correlated-value-propagation.NumPhis             |     15366 |     15381 |    15 |  0.0976% |
| correlated-value-propagation.NumSExt             |      6273 |      6277 |     4 |  0.0638% |
| correlated-value-propagation.NumShlNSW           |      1172 |      1171 |    -1 | -0.0853% |
| correlated-value-propagation.NumShlNUW           |      2793 |      2794 |     1 |  0.0358% |
| correlated-value-propagation.NumSubNSW           |       730 |       736 |     6 |  0.8219% |
| correlated-value-propagation.NumSubNUW           |      2044 |      2046 |     2 |  0.0978% |
| correlated-value-propagation.NumSubNW            |      2774 |      2782 |     8 |  0.2884% |
| instcount.NumAddInst                             |    277586 |    277569 |   -17 | -0.0061% |
| instcount.NumAndInst                             |     66056 |     66054 |    -2 | -0.0030% |
| instcount.NumBrInst                              |    709147 |    709146 |    -1 | -0.0001% |
| instcount.NumCallInst                            |    528579 |    528576 |    -3 | -0.0006% |
| instcount.NumExtractValueInst                    |     18307 |     18301 |    -6 | -0.0328% |
| instcount.NumOrInst                              |    102660 |    102665 |     5 |  0.0049% |
| instcount.NumPHIInst                             |    318008 |    318007 |    -1 | -0.0003% |
| instcount.NumSelectInst                          |     46373 |     46370 |    -3 | -0.0065% |
| instcount.NumSExtInst                            |     79496 |     79488 |    -8 | -0.0101% |
| instcount.NumShlInst                             |     40654 |     40657 |     3 |  0.0074% |
| instcount.NumTruncInst                           |     62251 |     62249 |    -2 | -0.0032% |
| instcount.NumZExtInst                            |     68211 |     68221 |    10 |  0.0147% |
| instcount.TotalBlocks                            |    843910 |    843909 |    -1 | -0.0001% |
| instcount.TotalInsts                             |   7387448 |   7387423 |   -25 | -0.0003% |

Reviewers: nikic, reames

Reviewed By: nikic

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Member operator declarations and member operator expressions
have different numbering of parameters and arguments respectively:
one of them includes "this", the other does not.

Account for this inconsistency when figuring out whether
the parameter needs to be manually rebound from the Environment
to the Store when entering a stack frame of an operator call,
as opposed to being constructed with a constructor and as such
already having the necessary Store bindings.

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

Testing git commit access.

- Reduce code duplication
- Get partial support of JAL expansion for XGOT.

This reverts commit 7bc7fe6b.
The immediate callers have been fixed to pass nullopt where appropriate.

Reviewers: sammccall

Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Summary:
This has been tested with gcc trunk on openSUSE Tumbleweed on the HiFive Unleashed.

Patch by Andreas Schwab (schwab)

Reviewers: luismarques

Reviewed By: luismarques

Subscribers: mhorne, emaste, luismarques, asb, mgorny, fedor.sergeev, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, lenary, s.egerton, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

This reverts commit 40668abc.
This causes clang tests to fail, as stacksize=0 is being explicitly passed and
is no longer a no-op.

This roughly mimics `std::thread(...).detach()` except it allows to
customize the stack size. Required for https://reviews.llvm.org/D50993.

I've decided against reusing the existing `llvm_execute_on_thread` because
it's not obvious what to do with the ownership of the passed
function/arguments:

1. If we pass possibly owning functions data to `llvm_execute_on_thread`,
   we'll lose the ability to pass small non-owning non-allocating functions
   for the joining case (as it's used now). Is it important enough?
2. If we use the non-owning interface in the new use case, we'll force
   clients to transfer ownership to the spawned thread manually, but
   similar code would still have to exist inside
   `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same
   non-owning pointer to pthreads and Windows implementations, and would be
   forced to wrap it in some structure, and deal with its ownership.

Patch by Dmitry Kozhevnikov!

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

MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64
regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo
we can find out Mips ABI and pick appropriate prefix.

Tags: #llvm, #clang, #lldb

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

Summary:
The default implementation of the describeLoadedValue() hook uses the
MoveImm property to determine if an instruction moves an immediate. If
an instruction has that property the function returns the second
operand, assuming that that is the immediate value the instruction
moves. As far as I can tell, the MoveImm property does not imply that
the second operand is the immediate value, nor that any other operand
necessarily holds the immediate value; it just means that the
instruction moves some immediate value.

One example where the second operand is not the immediate is SystemZ's
LZER instruction, which moves a zero immediate implicitly: $f0S = LZER.

That case triggered an out-of-bound assertion when getting the operand.
I have added a test case for that instruction.

Another example is ARM's MVN instruction, which holds the logical
bitwise NOT'd value of the immediate that is moved. For the following
reproducer:

  extern void foo(int);
  int main() { foo(-11); }

an incorrect call site value would be emitted:

  $ clang --target=arm foo.c -O1 -g -Xclang -femit-debug-entry-values \
      -c -o - | ./build/bin/llvm-dwarfdump  - | \
      grep -A2 call_site_parameter

  0x00000058:       DW_TAG_GNU_call_site_parameter
                      DW_AT_location (DW_OP_reg0 R0)
                      DW_AT_GNU_call_site_value (DW_OP_lit10)

Another example is the A2_combineii instruction on Hexagon which moves
two immediates to a super-register: $d0 = A2_combineii 20, 10.

Perhaps these are rare exceptions, and most MoveImm instructions hold
the immediate in the second operand, but in my opinion the default
implementation of the hook should only describe values that it can, by
some contract, guarantee are safe to describe, rather than leaving it up
to the targets to override the exceptions, as that can silently result
in incorrect call site values.

This patch adds X86's relevant move immediate instructions to the
target's hook implementation, so this commit should be a NFC for that
target. We need to do the same for ARM and AArch64.

Reviewers: djtodoro, NikolaPrica, aprantl, vsk

Reviewed By: vsk

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #debug-info, #llvm

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

A test commit.

Select vector G_MUL for MIPS32 with MSA. We have to set bank
for vector operands to fprb and selectImpl will do the rest.
Manual selection of G_MUL is now done for gprb only.
__builtin_msa_mulv_<format> will be transformed into G_MUL
in legalizeIntrinsic and selected in the same way.

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

Select vector G_SUB for MIPS32 with MSA. We have to set bank
for vector operands to fprb and selectImpl will do the rest.
__builtin_msa_subv_<format> will be transformed into G_SUB
in legalizeIntrinsic and selected in the same way.
__builtin_msa_subvi_<format> will be directly selected into
SUBVI_<format> in legalizeIntrinsic.

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

We should do the fold only if both constants are plain,
non-opaque constants, at least that is the DAG.FoldConstantArithmetic()
requirement.
And if the constant we are comparing with is zero - we shouldn't be
trying to do this fold in the first place.

Fixes https://bugs.llvm.org/show_bug.cgi?id=43769

This adds some initial syntactic checking that only the appropriate
function signatures can be defaulted. No implicit definitions are
generated yet.

(Testing git commit access.)

Reviewers: delcypher, beanz

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

This introduced new errors, see below. Reverting until that can be investigated
properly.

  #import <AVFoundation/AVFoundation.h>

  void f(int width, int height) {
    FourCharCode best_fourcc = kCMPixelFormat_422YpCbCr8_yuvs;
    NSDictionary* videoSettingsDictionary = @{
      (id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
    };
  }

  $ clang++ -c /tmp/a.mm

  /tmp/a.mm:6:5: error: cannot initialize a parameter of type
  'KeyType<NSCopying>  _Nonnull const' (aka 'const id') with an rvalue
  of type 'id'
      (id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc),
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1 error generated.

> When a category/extension doesn't repeat a type bound, corresponding
> type parameter is substituted with `id` when used as a type argument. As
> a result, in the added test case it was causing errors like
>
> > type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T'
>
> We are already checking that type parameters should be consistent
> everywhere (see `checkTypeParamListConsistency`) and update
> `ObjCTypeParamDecl` to have correct underlying type. And when we use the
> type parameter as a method return type or a method parameter type, it is
> substituted to the bounded type. But when we use the type parameter as a
> type argument, we check `ObjCTypeParamType` that ignores the updated
> underlying type and remains `id`.
>
> Fix by desugaring `ObjCTypeParamType` to the underlying type, the same
> way we are doing with `TypedefType`.
>
> rdar://problem/54329242
>
> Reviewers: erik.pilkington, ahatanak
>
> Reviewed By: erik.pilkington
>
> Subscribers: jkorous, dexonsmith, ributzka, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D66696

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

Breaks sanitizer-android buildbot.

This reverts commit d5620320.

This adds support for reserving GPRs such that the compiler will not
choose a register for register allocation. The implementation follows
the same design as for AArch64; each reserved register becomes a target
feature and used for getting the reserved registers for a given
MachineFunction. The backend checks that it does not need to write to
any reserved register; if it does a relevant error is generated.

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