Now that the Xcode project is removed, I want to focus on dotest as a
test framework, and remove its driver capabilities for which we already
rely on llvm's lit. Removing multiprocessing is the first step in that
direction.

Differential revision: https://reviews.llvm.org/D65311

llvm-svn: 367331

It's not useful anymore: we mandate C++11, and already use alignas in a bunch of places.

llvm-svn: 367330

Summary:
- The following stripped code trigger a gcc-4.8 bug. To work that
  around, move the alignment evaluation into template parameter.

```
// https://godbolt.org/z/58p5_X
//

enum { aligned = 0, unaligned = 1 };

template <typename T, int alignment> struct PickAlignment {
  enum { value = alignment == 0 ? alignof(T) : alignment };
};

template <typename ValueType, std::size_t Alignment> struct packed {
private:
  struct {
    alignas(
        PickAlignment<ValueType, Alignment>::value) char buffer[sizeof(int)];
  } Value;
};

using ule16_t = packed<uint16_t, unaligned>;

ule16_t x;
```

- Also, replace `alignas` with `LLVMALIGN_AS` to improve the compiler
  compatibility.

Reviewers: jfb

Subscribers: dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 367329

The default mode is separate, where the metadata is serialized
separately from the remarks.

Another mode is the standalone mode, where the metadata is serialized
before the remarks, on the same stream.

llvm-svn: 367328

Summary:
This patch extends the use of the OptimizationRemarkEmitter to provide
information about loops that are not fused, and loops that are not eligible for
fusion. In particular, it uses the OptimizationRemarkAnalysis to identify loops
that are not eligible for fusion and the OptimizationRemarkMissed to identify
loops that cannot be fused.

It also reuses the statistics to provide the messages used in the
OptimizationRemarks. This provides common message strings between the
optimization remarks and the statistics.

I would like feedback on this approach, in general. If people are OK with this,
I will flesh out additional remarks in subsequent commits.

Subscribers: hiraditya, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 367327

Empty condition strings are considerde always true. This removes a lot
of clutter from the generated matcher tables.

This shrinks the source size of AMDGPUGenDAGISel.inc from 7.3M to
6.1M.

llvm-svn: 367326

The @srem_of_srem_expanded case exposed a RAUW pitfall in D65298.
Right now these don't appear to fail verification,
so it should be safe to precommit them.

https://reviews.llvm.org/D65298
https://bugs.llvm.org/show_bug.cgi?id=42823
https://reviews.llvm.org/D65451

llvm-svn: 367325

Addresses number of comment made on D64652 after commiting:

- Reorders function decls in the TargetLoweringObjectFileXCOFF class.
- Fix comment in MCSectionXCOFF to include description of external reference
  csects.
- Convert several llvm_unreachables to report_fatal_error
- Convert several dyn_casts to casts as they are expected not to fail.
- Avoid copying DataLayout object.

llvm-svn: 367324

In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins.

Fixes https://llvm.org/pr42775

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

llvm-svn: 367323

Summary:
I have stumbled into this by accident while preparing to extend backend `x s% C ==/!= 0` handling.

While we did happen to handle this fold in most of the cases,
the folding is indirect - we fold `x u% y` to `x & (y-1)` (iff `y` is power-of-two),
or first turn `x s% -y` to `x u% y`; that does handle most of the cases.
But we can't turn `x s% INT_MIN` to `x u% -INT_MIN`,
and thus we end up being stuck with `(x s% INT_MIN) == 0`.

There is no such restriction for the more general fold:
https://rise4fun.com/Alive/IIeS

To be noted, the fold does not enforce that `y` is a constant,
so it may indeed increase instruction count.
This is consistent with what `x u% y`->`x & (y-1)` already does.
I think it makes sense, it's at most one (simple) extra instruction,
while `rem`ainder is really much more un-simple (and likely **very** costly).

Reviewers: spatel, RKSimon, nikic, xbolva00, craig.topper

Reviewed By: RKSimon

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367322

This can reduce unexpectedly pushing more than expected by the user.

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

llvm-svn: 367321

Instead of displaying a help message, it was issuing an error message:

  AttributeError: 'Namespace' object has no attribute 'func'

https://bugs.python.org/issue16308 has more information on the bug.

llvm-svn: 367320

llvm-svn: 367319

[X86] SimplifyDemandedVectorEltsForTargetNode should be calling resolveTargetShuffleInputs not getTargetShuffleMask

Add TODO comment.

llvm-svn: 367318

[cpp.predefined]p2:

   __STDCPP_THREADS__
    Defined, and has the value integer literal 1, if and only if a program
    can have more than one thread of execution .

Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.

Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).

Part of PR33230. The intent is to eventually make the compiler define
this instead.

llvm-svn: 367316

  $ ninja -j800
  [1/5] ACTION //libcxx/src:cxx_linker_script(//llvm/utils/gn/build/toolchain:stage2_unix)
  FAILED: lib/libc++.so
  python ../libcxx/utils/gen_link_script.py --input //build.gn/lib/libc++.so.0 --output //build.gn/lib/libc++.so c++abi unwind
  GENERATING SCRIPT: 'INPUT(libc++.so.0 -lc++abi -lunwind)' as file //build.gn/lib/libc++.so
  Traceback (most recent call last):
    File "../libcxx/utils/gen_link_script.py", line 57, in <module>
      sys.exit(main())
    File "../libcxx/utils/gen_link_script.py", line 50, in main
      with open(args.output, 'w') as f:
  IOError: [Errno 2] No such file or directory: '//build.gn/lib/libc++.so'
  ninja: build stopped: subcommand failed.

Differential revision: https://reviews.llvm.org/D65449

llvm-svn: 367314

Summary: That patch made the tweak always annotate the whole file by accident.

Reviewers: jvikstrom

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 367313

When dumping a desugared QualType and the type is a type alias, also print out the id for the type alias declaration.

llvm-svn: 367312

These tests have been disabled on Linux and Windows due to failing
there. I think that could be down to a race condition between stdout
and stderr, so I have disabled output to stdout.

For the moment, only re-enable on linux, because I don't have a windows
machine to test on.

llvm-svn: 367311

Initially Inputs/alloc-symtab.o was added in D42222.
It contains an allocatable .symtab section. Today
we are able to create such sections using yaml2obj.

Later people started using this input for no solid reason in their tests.
Now multiple of tests are using it. 
(And those tests do not need such a specific case actually).

In this patch I removed this binary and rewrote the few tests.

Differential revision: https://reviews.llvm.org/D65278

llvm-svn: 367310

These tests currently pass, but they rely on fix-its in our expression
parser to pass because they have some typos.

llvm-svn: 367309

Summary:
Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way
to do this is to go inside a frame with at least one local variable and then try to complete:

    (lldb) expr
    1. a[tab]

Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate
the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to
become -1 which will lead to some out-of-bounds reading).

Fixes rdar://51754005

I don't see any way to test this as the *multiline* expression completion is completely untested at the moment
and I don't think we have any existing code for testing infrastructure for it.

Reviewers: shafik, davide, labath

Reviewed By: labath

Subscribers: abidh, lldb-commits, davide, clayborg, labath

Tags: #lldb

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

llvm-svn: 367308

llvm-svn: 367307

[X86][AVX] SimplifyDemandedVectorElts - handle extraction from X86ISD::SUBV_BROADCAST source (PR42819)

PR42819 showed an issue that we couldn't handle the case where we demanded a 'sub-sub-vector' of the SUBV_BROADCAST 'sub-vector' source.

This patch recognizes these cases and extracts the sub-sub-vector instead of trying to broadcast to a type smaller than the 'sub-vector' source. 

llvm-svn: 367306

make check-all currently fails on x86_64-pc-solaris2.11 when building with GCC 9:

  Undefined                       first referenced
   symbol                             in file
  _ZN11__sanitizer14internal_lseekEimi SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
  _ZN11__sanitizer23MapWritableFileToMemoryEPvmim SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
  ld: fatal: symbol referencing errors
  clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
  make[3]: *** [projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/TSanitizer-i386-Test.dir/build.make:92: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test] Error 1

While e.g. __sanitizer::internal_lseek is defined in sanitizer_solaris.cc, g++ 9
predefines _FILE_OFFSET_BITS=64 while clang++ currently does not.

This patch resolves this inconsistency by following the gcc lead, which allows
make check-all to finish successfully.

There's one caveat: gcc defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for C++ only, while clang has long been doing it for
all languages.  I'd like to keep it this way because those macros do is to make
declarations of fseek/ftello (_LARGEFILE_SOURCE) resp. the 64-bit versions
of largefile functions (*64 with _LARGEFILE64_SOURCE) visible additionally.
However, _FILE_OFFSET_BITS=64 changes all affected functions to be largefile-aware.
I'd like to restrict this to C++, just like gcc does.

To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64
(e.g. clang < 9, gcc < 9), this needs a compantion patch https://reviews.llvm.org/D64483.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 367305

This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure
that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on
Solaris succeed by always making the host and freshly built clang consistent.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 367304

Summary:
This fixes a case where we show diagnostics on arbitrary lines, in an
internal codebase.

Open for ideas on unittesting this.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

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

llvm-svn: 367303

Summary: The lldb build system made good progress in the last months, but documentation was still lacking behind. Here's a patch to catch up.

Reviewers: JDevlieghere, jingham, labath, stella.stamenova, teemperor, jryans, kastiglione, xiaobai, compnerd, zturner

Reviewed By: labath, stella.stamenova, jryans

Subscribers: clayborg, amccarth, friss, lldb-commits, #lldb

Tags: #lldb

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

llvm-svn: 367302

The Arm C Language Extensions for SVE document specifies that 
__ARM_FEATURE_SVE should be set when the compiler supports SVE and
implements all the extensions described in the document.

This is currently not yet the case, so the feature should be disabled
until the compiler can provide all the extensions as described.

Reviewers: c-rhodes, rengolin, rovka, ktkachov

Reviewed By: rengolin

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

llvm-svn: 367301

This time, the warning pointed to an actual problem, because the
coff_opt_header structure contained a std::vector. I guess this happened
to work because the all-zero state was a valid representation of an
empty vector, but its not a good idea to rely on that.

I remove the memset, and have the structure clear its members in the
constructor instead.

llvm-svn: 367299

Summary:
The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking in
a central place, we weren't really succesful in doing that right now,
because some SymbolFile function could still be called without going
through the SymbolVendor. This meant in SymbolFileDWARF (the only
battle-tested symbol file implementation) roughly a half of the
functions was taking additional locks and another half was asserting
that the lock is already held. By making the SymbolFile responsible for
locking, we can at least make the situation in SymbolFileDWARF more
consistent.

Reviewers: clayborg, JDevlieghere, jingham, jdoerfert

Subscribers: aprantl, lldb-commits

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

llvm-svn: 367298

The code is now in a good enough state to pass the bunch of tests that
I have run (after fixing the bugs), so let's enable it by default.

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

llvm-svn: 367297

    
Revert the hardware loop upon finding a LoopEnd that doesn't target
the loop header, instead of asserting a failure.

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

llvm-svn: 367296

Two SPARC builtins tests are currently FAILing due to codegen bugs:

  Builtins-sparc-sunos :: divtc3_test.c
  Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
  Builtins-sparcv9-sunos :: divtc3_test.c

I'd like to XFAIL them to reduce testsuite noise. 
  
Done as follows, tested on sparcv9-sun-solaris2.11 and x86_64-pc-solaris2.11.

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

llvm-svn: 367295

[NFC][X86][AArch64] Revisit test coverage for X s% C == 0 fold - add tests for negative divisors, INT_MIN divisors

As discussed in the review, that fold is only valid for positive
divisors, so while we can negate negative divisors,
we have to special-case INT_MIN.

llvm-svn: 367294

AddressSanitizer-*-sunos :: TestCases/intercept-rethrow-exception.cc currently FAILs
on Solaris.  This happens because std::rethrow_exception cannot be intercepted, as
detailed in Bug 42703.

To account for this and reduce testsuite noise, this patch XFAILs the test.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 367293

Summary:
Patch removes SVE and SVE2 features from ARMTargetParser as these
features are not supported on ARM.

Reviewed By: rengolin

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

llvm-svn: 367292

Compare the directory paths returned by lldb-vscode against realpaths
rather than apparent paths.  This matches lldb-vscode behavior
and therefore fixes test failures when one of the parent directories
of the source tree is a symlink.

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

llvm-svn: 367291

Replace os.path.split()[0] with os.path.dirname().  Suggested by Pavel
Labath in D65432.

llvm-svn: 367290

test-suite/MultiSource/Benchmarks/DOE-ProxyApps-C/miniGMG broke:

Only PHI nodes may reference their own value!
  %sub33 = srem i32 %sub33, %ranks_in_i

This reverts commit r367288.

llvm-svn: 367289