[python] [tests] Fix calling tests on Windows

Fix passing arguments to the Python test command to use 'env' builtin
CMake command, in order to fix compatibility with Windows.

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

llvm-svn: 344288

[WebAssembly][NFC] Remove repetition of Defs = [ARGUMENTS] (fixed)

llvm-svn: 344287

Update test of r344198 to work with release builds.

llvm-svn: 344286

[HIP] Remove unused irif bitcode from test

This is part of previous commit [HIP] Replace irif library with hip.amdgcn.bc

Reviewers: yaxunl

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

llvm-svn: 344285

[Hexagon] Restrict compound instructions with constant value.

Having a constant value operand in the compound instruction
is not always profitable. This patch improves coremark by ~4% on
Hexagon.

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

llvm-svn: 344284

[Pipeliner] Use the Index from Topo instead of relying on NodeNum. (NFC)

In future, if we may add any new DAG mutations other than artificial dependencies,
the NodeNum may not be valid. Instead the index from topological schedule DAG can be
used as long as we update it with the DAG change.

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

llvm-svn: 344283

[Pipeliner] Fix the Schedule DAG topoligical order.

This patch updates the DAG change to reflect in the topological ordering
of the nodes.

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

llvm-svn: 344282

[HIP] Replace irif library with hip.amdgcn.bc

No longer use irif amdgcn library, instead we will use the previous fence functions from new hip.amdgcn.bc bitcode library. Update hip-device-libs.hip test as well.

llvm-svn: 344281

[WebAssembly] Revert rL344180, which was breaking expensive checks

llvm-svn: 344280

Revert SymbolFileNativePDB plugin.

This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker.  After
those fixes, however, other tests started failing.  Reverting
temporarily until I can address everything.

llvm-svn: 344279

Revert r344197 "[MC][ELF] compute entity size for explicit sections"

Revert r344206 "[MC][ELF] Fix section_mergeable_size.ll"

They were causing failures on too many important buildbots for too long.
Please revert eagerly if your fix takes more than a couple of hours to land!

llvm-svn: 344278

Fix this comment so it is consistent with all the others.

llvm-svn: 344277

Revert "clang-cl: Add /showFilenames option (PR31957)"

This reverts https://reviews.llvm.org/rL344234 which is causing failures on
several bots due to invalid llvm.linker.options.

llvm-svn: 344276

Don't mark an LC_BUILD_VERSION as giving us a
correct version if it has a major verison 0.

llvm-svn: 344275

[PassManager/Sanitizer] Port of AddresSanitizer pass from legacy to new PassManager

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

[OPENMP][NVPTX]Reduce memory use for globalized vars in
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

[DAG] Fix Big Endian in Load-Store forwarding

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

[Hexagon] Eliminate potential sources of non-determinism in HCE

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

Better support for POSIX paths in PDBs.

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

[llvm-nm] Fix crash when running with --print-armap on corrupt archives.

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

Revert "[Lex] TokenConcatenation now takes const Preprocessor"

This reverts commit r344262. This was an unintentional commit.

llvm-svn: 344267

clang-cl: set output of lit-test to a tmp file after r344234

Some test frameworks do not allow output file in CWD.

llvm-svn: 344266

[COFF] Add and use a Wordsize field in Config. NFCI.

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

llvm-svn: 344265

[COFF] Set proper pointer size alignment for LocalImportChunk

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

[python] [tests] Retab CMakeLists.txt for consistency (NFC)

llvm-svn: 344263

[Lex] TokenConcatenation now takes const Preprocessor

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

llvm-svn: 344262

Revert commit r344254; does not work with C++03

llvm-svn: 344261

[tests] Remove Python tests from check-all due to breakage

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

Improve -Wshadow warnings with enumerators.

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

[tests] Include Python binding tests in CMake rules

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

Some improvements to the OpenBSD driver.

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

llvm-svn: 344257

[clang-move] Remove clang:: qualifier

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

[DAGCombiner] move comment closer to the corresponding code; NFC

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-mca][BtVer2] Add tests for optimizable GPR register moves. NFC

llvm-svn: 344253

[lldb] Surpress copy-elison warning.

llvm-svn: 344252

[InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had references to it.

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

[lldb] rename MinOS::minor to MinOS::minor_version etc. NFC

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

[AARCH64][FIX] Emit data symbol for constant pool data

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

[Tooling] Move CompilationDatabasePlugin to the Registry header, where it's useful. NFC

llvm-svn: 344247

[Sema][OpenCL] Improve diagnostics for not viable overloadable function candidates

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

[clangd] Remove no-op crash handler, we never set a crash context.

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

Revert r344241 as it broke multiple bots.

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

Generalize an IR verifier check to work with non-zero program address spaces

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

[analyzer][UninitializedObjectChecker] Reports Loc fields pointing to themselves

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

[tests] Include Python binding tests in CMake rules

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

[python] [tests] Support overriding library path via environment

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

[InstCombine] Demand bits of UMin

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

[RISCV] Re-generate test/CodeGen/RISCV/vararg.ll after r344142

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

llvm-svn: 344238

[InstCombine] Demand bits of UMax

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

[InstCombine] Add tests for demand bits of min/max. NFC.

llvm-svn: 344236

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

llvm-svn: 344235

clang-cl: Add /showFilenames option (PR31957)

Add a /showFilenames option for users who want clang to echo the
currently compiled filename. MSVC does this echoing by default, and it's
useful for showing progress in build systems that doesn't otherwise
provide any progress report, such as MSBuild.

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

llvm-svn: 344234

[LV] Use SmallVector instead of DenseMap in calculateRegisterUsage (NFC).

We assign indices sequentially for seen instructions, so we can just use
a vector and push back the seen instructions. No need for using a
DenseMap.

Reviewers: hsaito, rengolin, nadav, dcaballe

Reviewed By: rengolin

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

llvm-svn: 344233

[LV] Ignore more debug info.

We can avoid doing some unnecessary work by skipping debug instructions
in a few loops. It also helps to ensure debug instructions do not
prevent vectorization, although I do not have any concrete test cases
for that.

Reviewers: rengolin, hsaito, dcaballe, aprantl, vsk

Reviewed By: rengolin, dcaballe

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

llvm-svn: 344232

[compiler-rt][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and signed checks

Summary:
This is compiler-rt part.
clang part is D50901.

Reviewers: rsmith, vsk, filcab, Sanitizers

Reviewed by: filcab

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

llvm-svn: 344231

[clang][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and signed checks

Summary:
As per IRC disscussion, it seems we really want to have more fine-grained `-fsanitize=implicit-integer-truncation`:
* A check when both of the types are unsigned.
* Another check for the other cases (either one of the types is signed, or both of the types is signed).

This is clang part.
Compiler-rt part is D50902.

Reviewers: rsmith, vsk, Sanitizers

Reviewed by: rsmith

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

llvm-svn: 344230

[profile] Fix the gcov tests after the patch in D49853 landed.

Summary:
The goal of the patch in D49853 is to display counter on the line of function definition.
So some tests need to be fixed.

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: sylvestre.ledru, delcypher, llvm-commits, #sanitizers

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

llvm-svn: 344229

[gcov] Display the hit counter for the line of a function definition

Summary:
Right now there is no hit counter on the line of function.
So the idea is add the line of the function to all the lines covered by the entry block.
Tests in compiler-rt/profile will be fixed in another patch: https://reviews.llvm.org/D49854

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: sylvestre.ledru, llvm-commits

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

llvm-svn: 344228

[NFC] Factor out getOrCreateAddRecExpr method

llvm-svn: 344227

[ELF] - Set sh_info and sh_link for .rela.plt sections.

This is https://bugs.llvm.org/show_bug.cgi?id=37538,

Currently, LLD may set both sh_link and sh_info for
.rela.plt section to zero when we have only .rela.iplt section part used.

ELF spec (https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html)
says that for SHT_REL and SHT_RELA, sh_link references the associated symbol table
and sh_info the "section to which the relocation applies."

When we set the sh_link field, for the regular case we use the .dynsym index.
For .rela.iplt sections, it is unclear what is the associated symbol table,
because R_*_RELATIVE relocations do not use symbol names and we might have no
.dynsym section at all so this patch uses .symtab section index.

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

llvm-svn: 344226

Fix the qualification of `IntrusiveRefCntPtr` to use `llvm::`.

Without this, the code only compiled if the header was included after
something introduced the alias from `clang::` to `llvm::` for this type.
Any modules build would fail here.

llvm-svn: 344225

[X86][BMI1]: X86DAGToDAGISel: select BEXTR from x & ~(-1 << nbits) pattern

Summary:
As discussed in D48491, we can't really do this in the TableGen,
since we need to produce *two* instructions. This only implements
one single pattern. The other 3 patterns will be in follow-ups.

I'm not sure yet if we want to also fuse shift into here
(i.e `(x >> start) & ...`)

Reviewers: RKSimon, craig.topper, spatel

Reviewed By: craig.topper

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

llvm-svn: 344224

[IndVars] Drop "exact" flag from lshr and udiv when substituting their args

There is a transform that may replace `lshr (x+1), 1` with `lshr x, 1` in case
if it can prove that the result will be the same. However the initial instruction
might have an `exact` flag set, and it now should be dropped unless we prove
that it may hold. Incorrectly set `exact` attribute may then produce poison.

Differential Revision: https://reviews.llvm.org/D53061
Reviewed By: sanjoy

llvm-svn: 344223

[llvm-nm] Include the text "@FILE" in the output of --help

libtool requires this text to be present, in order to conclude that
the tool supports response files. Also add an explicit test of using
response files with llvm-nm.

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

llvm-svn: 344222

Add a test that shows what happens with throwing destructors. NFC.

llvm-svn: 344220

[CMake] Temporarily remove the LLVM_ENABLE_IDE option

All uses of this option have been removed, and the intent is to change the purpose and default value of this option. To prevent it from having impacts on users, this patch temporarily removes the option and purges it from CMake caches. In a few days, once this has propagated to contributors I will re-introduce the option with the new default value.

llvm-svn: 344219

[CMake] Unconditionally add .h and .td files to target sources

Previously adding header and table gen files was conditional on using an IDE. Since these files have the `HEADER_FILE_ONLY` attribute applied they are ignored as sources by all non-IDE generators, so there is really no reason not to include them.

Additionally having the CMake always include these files allows the CMake-server to include them in the sources list for targets, which is valuable to anyone using CMake-server integrated tools.

llvm-svn: 344218

[Coverage] Apply filtered paths to summary

Summary:
The script to generate code coverage reports supports passing filter paths to llvm-cov when generating the HTML reports, but doesn't pass those paths to the summary generation as well. This results in a summary report that doesn't match the HTML report.

This patch addresses the problem by also passing the filter paths to the summary report generation.

Reviewers: vsk

Subscribers: llvm-commits

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

llvm-svn: 344217

Use fully qualified namespace name.

llvm::detail is not the only namespace named detail.  So if
someone has done a `using namespace llvm::support`, for example,
this will fail with an ambiguous namespace name.  Granted
people generally shouldn't be using large namespaces like that,
but it's common at local function scopes.

llvm-svn: 344216

Use C++03 friendly version of alignof

llvm-svn: 344215

Fix use of removed _LIBCPP_HAS_NO_BUILTIN_ALIGNED_OPERATOR_NEW_DELETE

It was replaced with the better named
_LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE.

llvm-svn: 344214

[hwasan] extend the stack-uar test

llvm-svn: 344213

Eliminate dependency to formatv(). NFC.

llvm-svn: 344212

[WebAssembly][NFC] Use intrinsic dag nodes directly

Summary: Instead of custom lowering to WebAssemblyISD nodes first.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 344211

[hwasan] more compact printing for 'Previosly allocated frames'

llvm-svn: 344210

Upstreaming the BridgeOS device support and the
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself.  llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.

Also update Xcode project file to build the
NativePDB etc plugins.

<rdar://problem/43353615>

llvm-svn: 344209

Update libc++abi's detection of aligned allocation after r344207.

llvm-svn: 344208

Distinguish between library and language support for aligned allocation.

There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.

There are times where libc++ needs to distinguish between the two.

This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.

Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.

llvm-svn: 344207

[MC][ELF] Fix section_mergeable_size.ll

Some targets use %progbits instead of @progbits.

Updating that check with a {{[@%]}}progbits regex to make those bots happy.

llvm-svn: 344206

[WebAssembly] Saturating float-to-int builtins

Summary: Depends on D53007 and D53004.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, kristina, cfe-commits

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

llvm-svn: 344205

[WebAssembly] Saturating float to int intrinsics

Summary:
Although the saturating float to int instructions are already
emitted from normal IR, the fpto{s,u}i instructions produce poison
values if the argument cannot fit in the result type. These intrinsics
are therefore necessary to get guaranteed defined saturating behavior.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 344204

[hwasan] simplify a test

llvm-svn: 344203

llvm-c: Add C APIs to access DebugLoc info

Add thin shims to C interface to provide access to DebugLoc info for
Instructions, GlobalVariables and Functions.  Patch by Josh Berdine!

llvm-svn: 344202

Update documentation to indicate that profile remapping support is only
implemented for the new pass manager so far.

llvm-svn: 344201

Add a flag to remap manglings when reading profile data information.

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

This is the LLVM side of Clang r344199.

Reviewers: davidxl, tejohnson, dlj, erik.pilkington

Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits

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

llvm-svn: 344200

Add a flag to remap manglings when reading profile data information.

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

llvm-svn: 344199

[LTO] Account for overriding lib calls via the alias attribute

Given a library call that is represented as an llvm intrinsic call, but
later transformed to an actual call, if an overriding definition of that
library routine is provided indirectly via an alias, prevent LTO from
eliminating the definition.

This is a fix for PR38547.

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

llvm-svn: 344198

[MC][ELF] compute entity size for explicit sections

Summary:
Global variables might declare themselves to be in explicit sections.
Calculate the entity size always to prevent assembler warnings
"entity size for SHF_MERGE not specified" when sections are to be
marked merge-able.

Fixes PR31828.

Reviewers: rnk, echristo

Reviewed By: rnk

Subscribers: llvm-commits, pirama, srhines

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

llvm-svn: 344197

Make a member function private and rename it to avoid function overloading.

llvm-svn: 344196

[ELF] Don't warn on undefined symbols if UnresolvedPolicy::Ignore is used

Summary:
Add a condition UnresolvedPolicy::Ignore to elf::warnUnorderedSymbol to suppress Sym->isUndefined() warnings from both

1) --symbol-ordering-file=
2) .llvm.call-graph-profile

If --unresolved-symbols=ignore-all is used,

  no "undefined symbol" error/warning is emitted. It makes sense to not warn unorderable symbols.

Otherwise,

  If an executable is linked, the default policy UnresolvedPolicy::ErrorOrWarn will issue a "undefined symbol" error. The unorderable symbol warning is redundant.

  If a shared object is linked, it is possible that only part of object files are used and some symbols are left undefined. The warning is not very necessary.
    In particular for .llvm.call-graph-profile, when linking a shared object, a call graph profile may contain undefined symbols. This case generated a warning before but it will be suppressed by this patch.

Reviewers: ruiu, davidxl, espindola

Reviewed By: ruiu

Subscribers: grimar, emaste, arichardson, llvm-commits

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

llvm-svn: 344195

Use TEST_STD_VER instead of __cplusplus [NFC]

While __cplusplus was only used a few dozen times, TEST_STD_VAR is used
more than 2000 times. So we replace the former by the latter for
consistency in the tests. There should be no functional change.

llvm-svn: 344194

[hwasan] when reporting a bug, print some very basic information about the heap chunk (in addition to the more detailed info that we may fail to show)

llvm-svn: 344193

Use std::scoped_lock only for C++17 and newer

This fixes a test failure caused by D53049.

llvm-svn: 344192

[libcxxabi] Allow building with sanitizers enabled

Summary:
I copied the sanitizer-related logic in libcxx/lib/CMakeLists.txt. In
the future, it would be great to avoid duplicating this logic in the
compiler, libc++ and libc++abi.

Reviewers: EricWF

Subscribers: mgorny, christof, dexonsmith, libcxx-commits, davide

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

llvm-svn: 344191

[AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals

Summary:
In r340386 we added code to give static locals in inline functions
default visibility. Instead, we should use the "default" visibility
passed on the command line, which could be hidden or protected, as GCC
does.

Some code bases use both -fvisibility=hidden and
-fvisibility-inlines-hidden to hide inline functions of classes that are
explicitly marked with default visibility.

Fixes PR39236

Reviewers: hans, thakis

Subscribers: eraman, llvm-commits

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

llvm-svn: 344190

[X86] Prevent non-temporal loads from folding into instructions by blocking them in X86DAGToDAGISel::IsProfitableToFold rather than with a predicate.

Remove tryFoldVecLoad since tryFoldLoad would call IsProfitableToFold and pick up the new check.

This saves about 5K out of ~600K on the generated isel table.

llvm-svn: 344189

[CMake] NFC. Updating documentation on options

The Ninja pool options are only supported with the Ninja generator and
should be called out as such.

llvm-svn: 344188