Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.

This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.

Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()

Previous version of this change (D31451) was rolled back due to an issue
with Objective-C selectors being incorrectly recognized as a C++ identifier.

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

llvm-svn: 299721

llvm-svn: 299720

llvm-svn: 299719

llvm-svn: 299718

The alignment expression cannot depend on '.', so we can compute it
early.

llvm-svn: 299717

This removes a bit more work from assignAddresses.

llvm-svn: 299716

llvm-svn: 299715

This adjusts header file includes for headers and source files
in Core.  In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway.  In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need.  Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.

llvm-svn: 299714

llvm-svn: 299713

This is possible in ways that are not compiler bugs,
so stop asserting on them.

This emits an extra error when emitting objects when it
can't encode the new pseudo, but I'm not sure that matters.

llvm-svn: 299712

We're using -nodefaultlibs to avoid the dependency on C++ library
when using check_cxx_compiler_flag, and as such we cannot use
check_cxx_compiler_flag to check the availability of -nodefaultlibs
itself.

llvm-svn: 299711

[InstCombine] When checking to see if we can turn subtracts of 2^n - 1 into xor, we only need to call computeKnownBits on the RHS not the whole subtract. While there use isMask instead of isPowerOf2(C+1)

Calling computeKnownBits on the RHS should allows us to recurse one step further. isMask is equivalent to the isPowerOf2(C+1) except in the case where C is all ones. But that was already handled earlier by creating a not which is an Xor with all ones. So this should be fine.

llvm-svn: 299710

This avoids calling it multiple times. In particular, we don't have to
call in in assignAddresses any more.

llvm-svn: 299709

FCOPYSIGN is lowered to bit operations which don't clear the high
bits.

llvm-svn: 299708

Preserve GlobalsAA analysis in memory intrinsic calls optimization based on
profiled size.

llvm-svn: 299707

Summary:
Particularly, with --delete, this can be very useful for testing
new optimizations on some hotspots, without having to run it on the whole
application. E.g. as such:
```
llvm-extract app.bc --recursive --rfunc .*hotspot.* > hotspot.bc
llvm-extract app.bc --recursive --delete --rfunc .*hotspot.* > residual.bc
llc -filetype=obj residual.bc > residual.o
llc -filetype=obj hotspot.bc > hotspot.o
cc -o app residual.o hotspot.o
```

Reviewed By: davide
Differential Revision: https://reviews.llvm.org/D31722

llvm-svn: 299706

llvm-svn: 299705

This combine is fully handled by SimplifyDemandedInstructionBits as of r299658 where I fixed this code to ensure the Add/Sub had only a single user. Otherwise it would fire and create additional instructions. That fix resulted in an improvement to code generated for tsan which is why I committed it before deleting.

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

llvm-svn: 299704

llvm-svn: 299703

This reverts commit r299699, the examples needs to be updated.

llvm-svn: 299702

In LowerMUL, the chain information is not preserved for the new
created Load SDNode.

For example, if a Store alias with one of the operand of Mul.
The Load for that operand need to be scheduled before the Store.
The dependence is recorded in the chain of Store, in TokenFactor.
However, when lowering MUL, the SDNodes for the new Loads for
VMULL are not updated in the TokenFactor for the Store. Thus the
chain is not preserved for the lowered VMULL.

llvm-svn: 299701

One FileID per warning will increase and overflow NextLocalOffset
when input file is large with many warnings.
Reusing FileID avoids this problem.

This requires changes in getColumnNumber, D31406, rL299681.

Differential Revision: http://reviews.llvm.org/D31406

llvm-svn: 299700

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr
to mark the end of the vararg, and there's not type checking on the
arguments. The variadic template is an obvious solution to both
issues.

Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu>

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

llvm-svn: 299699

This is a re-land of r298173, r298169, r298159.

llvm-svn: 299698

Use a combination of !associated, comdat, @llvm.compiler.used and
custom sections to allow dead stripping of globals and their asan
metadata. Sometimes.

Currently this works on LLD, which supports SHF_LINK_ORDER with
sh_link pointing to the associated section.

This also works on BFD, which seems to treat comdats as
all-or-nothing with respect to linker GC. There is a weird quirk
where the "first" global in each link is never GC-ed because of the
section symbols.

At this moment it does not work on Gold (as in the globals are never
stripped).

This is a re-land of r298158 rebased on D31358. This time,
asan.module_ctor is put in a comdat as well to avoid quadratic
behavior in Gold.

llvm-svn: 299697

When possible, put ASan ctor/dtor in comdat.

The only reason not to is global registration, which can be
TU-specific. This is not the case when there are no instrumented
globals. This is also limited to ELF targets, because MachO does
not have comdat, and COFF linkers may GC comdat constructors.

The benefit of this is a lot less __asan_init() calls: one per DSO
instead of one per TU. It's also necessary for the upcoming
gc-sections-for-globals change on Linux, where multiple references to
section start symbols trigger quadratic behaviour in gold linker.

This is a rebase of r298756.

llvm-svn: 299696

Create the constructor in the module pass.
This in needed for the GC-friendly globals change, where the constructor can be
put in a comdat  in some cases, but we don't know about that in the function
pass.

This is a rebase of r298731 which was reverted due to a false alarm.

llvm-svn: 299695

There doesn't seem to be any point in doing this.

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

llvm-svn: 299694

This replaces a few uses of basename with the recently introduced lit
replacements.

llvm-svn: 299693

Summary:
Prior to this while it would delete the dead DIGlobalVariables, it would
leave dead DICompileUnits and everything referenced therefrom. For a bit
bitcode file with thousands of compile units those dead nodes easily
outnumbered the real ones. Clean that up.

Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D31720

llvm-svn: 299692

Change constant address space from 4 to 2 for the new address space mapping in Clang.

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

llvm-svn: 299691

Our final address space mapping is to let constant address space to be 4 to match nvptx.
However for now we will make it 2 to avoid unnecessary work in FE/BE/devlib
about intrinsics returning constant pointers.

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

llvm-svn: 299690

This reverts commit 942d6e6f58bf7e63810dd7cbcbce1fdfa5ebc6d4.

Build breakage.

llvm-svn: 299689

Summary:
Fix case elided by rL298920.

Fixes PR32545.

Reviewers: eli.friedman, RKSimon

Subscribers: llvm-commits

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

llvm-svn: 299688

We have dedicated handlers for every opcode so nothing can get here anymore. The switch doesn't get detected as fully covered because Opcode is an unsigned. Casting to Instruction::BinaryOps still doesn't detect it because BinaryOpsEnd is in the enum and 1 past the last opcode.

llvm-svn: 299687

llvm-svn: 299686

llvm-svn: 299685

llvm-svn: 299684

llvm-svn: 299683

memorydefs, not just stores.  Along the way, we audit and fixup issues
about how we were tracking memory leaders, and improve the verifier
to notice more memory congruency issues.

llvm-svn: 299682