This patch ports the legacy pass manager to the new one to take advantage of
the benefits of the new PM. This involved moving a lot of the declarations for
`AddressSantizer` to a header so that it can be publicly used via
PassRegistry.def which I believe contains all the passes managed by the new PM.

This patch essentially decouples the instrumentation from the legacy PM such
hat it can be used by both legacy and new PM infrastructure.

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

llvm-svn: 344274

target/teams/distribute regions.

Previously introduced globalization scheme that uses memory coalescing
scheme may increase memory usage fr the variables that are devlared in
target/teams/distribute contexts. We don't need 32 copies of such
variables, just 1. Patch reduces memory use in this case.

llvm-svn: 344273

Summary:
Correct offset calculation in load-store forwarding for big-endian
targets.

Reviewers: rnk, RKSimon, waltl

Subscribers: sdardis, nemanjai, hiraditya, jrtc27, atanasyan, jsji, llvm-commits

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

llvm-svn: 344272

Also, avoid comparing GUIDs when ordering global addresses, because
source file location can cause different GUID to be calculated. As a
result, a pair of symbols can compare "less" in one directory, but
"greater" in another.

llvm-svn: 344271

[X86] Restore X86ISelDAGToDAG::matchBEXTRFromAnd. Teach address matching to create a BEXTR pattern from a (shl (and X, mask >> C1) if C1 can be folded into addressing mode.

This is an alternative to D53080 since I think using a BEXTR for a shifted mask is definitely an improvement when the shl can be absorbed into addressing mode. The other cases I'm less sure about.

We already have several tricks for handling an and of a shift in address matching. This adds a new case for BEXTR.

I've moved the BEXTR matching code back to X86ISelDAGToDAG to allow it to match. I suppose alternatively we could directly emit a X86ISD::BEXTR node that isel could pattern match. But I'm trying to view BEXTR matching as an isel concern so DAG combine can see 'and' and 'shift' operations that are well understood. We did lose a couple cases from tbm_patterns.ll, but I think there are ways to recover that.

I've also put back the manual load folding code in matchBEXTRFromAnd that I removed a few months ago in r324939. This gives us some more freedom to make decisions based on the ability to fold a load. I haven't done anything with that yet.

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

llvm-svn: 344270

While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.

The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).

There's changes in clang, LLD, and lldb in this patch.  After
this the cross-platform disassembly and source-list tests pass
on Linux.

Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.

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

llvm-svn: 344269

error() in llvm-nm intentionally does not return so that the callee can move on to future files/slices. When printing the archive map, this is not currently handled (the caller assumes that error() returns), so processing continues despite there being an error.

Also, change one return to a break, so that symbols can be printed even if the archive map is corrupt.

llvm-svn: 344268

This reverts commit r344262. This was an unintentional commit.

llvm-svn: 344267

Some test frameworks do not allow output file in CWD.

llvm-svn: 344266

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

llvm-svn: 344265

When these are accessed with load/store instructions on ARM64,
it becomes strictly necessary to have them properly aligned.

This fixes PR39228.

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

llvm-svn: 344264

llvm-svn: 344263

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

llvm-svn: 344262

llvm-svn: 344261

Remove the Python tests from default target in order to fix two
kinds of breakage uncovered by enabling them: one failing test on Linux,
and problem with the test command on Windows.  Both to be addressed
in followup revisions.

llvm-svn: 344260

Addresses PR24718 by checking for enumerators that shadow other enumerators. Catches issues like:

enum E1{e1};
void f(void) {
  enum E2{e1};
}

llvm-svn: 344259

Add a new CMake rule check-clang-python to run the Python bindings'
test suite, and include it in check-all.

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

llvm-svn: 344258

- OpenBSD has switched to compiler_rt / libcxx
- Fix sysroot and lib path handling
- Some cleaning up

llvm-svn: 344257

Summary:
The use sites are enclosed by `namespace clang`, so clang:: is not
necessary. Many unqualified names have already been used, e.g. SourceManager SourceLocation LangOptions. This change makes the code terser and more consistent.

Reviewers: hokein

Reviewed By: hokein

Subscribers: ioeric, cfe-commits

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

llvm-svn: 344256

llvm-svn: 344255

Prefer to use the __is_XXX compiler intrinsics to the (old, busted) __has_XXX intrinsics when implementing type traits. Thanks to Richard Smith for the patch.

llvm-svn: 344254

llvm-svn: 344253

llvm-svn: 344252

InstCombine keeps a worklist and assumes that optimizations don't
eraseFromParent() the instruction, which SimplifyLibCalls violates. This change
adds a new callback to SimplifyLibCalls to let clients specify their own hander
for erasing actions.

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

llvm-svn: 344251

The constructor initializer minor(...)/major(...) can be confused with system
macros `#define minor(...)` on some platforms.

llvm-svn: 344250

Add support for 'dynamic_allocators' clause on 'requires' directive. Differential Revision: https://reviews.llvm.org/D53079

llvm-svn: 344249

The ARM64 elf emitter would omit printing data
symbol for zero filled constant data. This patch
overrides the emitFill method as to enforce that
the symbol is correctly printed.

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

llvm-svn: 344248

llvm-svn: 344247

Summary:
Allowed extension name (that ought to be disabled) printing in the note message.

This diagnostic was proposed here: https://reviews.llvm.org/D51341

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: cfe-commits, asavonic, bader

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

llvm-svn: 344246

Summary:
I think this was just copied from somewhere with the belief that it actually
did some crash handling.

Of course the question arises: *should* we set one? I don't think so:
 - clangd used to crash a lot, now it's pretty stable, because we found and
   fixed the crashes. I think the long-term effects of crashing hard are good.
 - the implementation can't do any magic, it just uses longjmp to return without
   running any destructors by default. This is unsafe in general (e.g. mutexes
   won't unlock) and will certainly end up leaking memory. Whatever UB caused
   the crash may still stomp all over global state, etc.

I think there's an argument for isolating the background indexer (autoindex)
because it's not directly under the user's control, the crash surface is larger,
and it doesn't particularly need to interact with the rest of clangd.
But there, fork() and communicate through the FS is safer.

Reviewers: ioeric, ilya-biryukov

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

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

llvm-svn: 344245

http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/10814
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20613

llvm-svn: 344244

This commit modifies an existing IR verifier check that
assumes all functions will be located in the default address
space 0.

Rather than using the default paramater value getPointerTo(AddrSpace=0),
explicitly specify the program memory address space from the data layout.

This only affects targets that specify a nonzero address space
in their data layouts. The only in-tree target that does this
is AVR.

llvm-svn: 344243

I've added a new functionality, the checker is now able to
detect and report fields pointing to themselves. I figured
this would fit well into the checker as there's no reason
for a pointer to point to itself instead of being nullptr.

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

llvm-svn: 344242

Add a new CMake rule check-clang-python to run the Python bindings'
test suite, and include it in check-all.

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

llvm-svn: 344241

Support a new CLANG_LIBRARY_PATH environment variable for the Python
binding tests.  This variable can be used to force the bindings to load
libclang.* from a specific directory.

I plan to use this when integrating Python binding tests with the CMake
build system.  Currently, those tests load libclang.so from default
search paths, so I would have to rely on platform-specific mechanics
such as LD_LIBRARY_PATH.  Instead of copying the whole logic necessary
to handle platform differences into yet another place, it's easier to
just add a dedicated variable for this purpose.

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

llvm-svn: 344240

This is the umin alternative to the umax code from rL344237. We use
DeMorgans law on the umax case to bring us to the same thing on umin,
but using countLeadingOnes, not countLeadingZeros.

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

llvm-svn: 344239

The improved load-store forwarding committed in r344142 broke this test.

llvm-svn: 344238

Use the demanded bits of umax(A,C) to prove we can just use A so long as the
lowest non-zero bit of DemandMask is higher than the highest non-zero bit of C

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

llvm-svn: 344237

llvm-svn: 344236

[tblgen][CodeGenSchedule] Add a check for invalid RegisterFile definitions with zero physical registers.

llvm-svn: 344235