[WebAssembly] TableGen backend for stackifying instructions

Summary:
The new stackification backend generates the giant switch statement
used to translate instructions to their stackified forms. I did this
because it was more interesting than adding all the different vector
versions of the various SIMD instructions to the switch statment
manually.

Reviewers: aardappel, aheejin, dschuff

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

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

llvm-svn: 340781

Update the Visual Studio Integration from user feedback.

This patch removes the MSBuild warnings about options that
clang-cl ignores.  It also adds several additional fields to
the LLVM Configuration options page.  The first is that it
adds support for LLD!  To give the user flexibility though,
we don't want to force LLD to always-on, and if we're not
forcing LLD then we might as well not force clang-cl either.
So we add options that can enable or disable lld, clang-cl,
or any combination of the two.  Whenever one is disabled,
it falls back to the Microsoft equivalent.

Additionally, for each of clang-cl and lld-link, we add a new
configuration setting that allows Additional Options to be
passed for that specific tool only.  This is similar to the
C/C++ > Command Line > Additional Options entry box, but
it serves the use case where a user switches back and forth
between the toolsets in their vcxproj, but where cl.exe
won't accept some options that clang-cl will.  In this case
you can pass those options in the clang-cl additional options
and whenever clang-cl is disabled (or the other toolset is
selected entirely), those options won't get passed at all.

llvm-svn: 340780

Fix typo

llvm-svn: 340779

Fix ODR violation: namespace-scope helpers should not be declared 'static'.

llvm-svn: 340778

Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of SCEVs"

This reverts r319889.

Unfortunately, wrapping flags are not a part of SCEV's identity (they
do not participate in computing a hash value or in equality
comparisons) and in fact they could be assigned after the fact w/o
rebuilding a SCEV.

Grep for const_cast's to see quite a few of examples, apparently all
for AddRec's at the moment.

So, if 2 expressions get built in 2 slightly different ways: one with
flags set in the beginning, the other with the flags attached later
on, we may end up with 2 expressions which are exactly the same but
have their operands swapped in one of the commutative N-ary
expressions, and at least one of them will have "sorted by complexity"
invariant broken.

2 identical SCEV's won't compare equal by pointer comparison as they
are supposed to.

A real-world reproducer is added as a regression test: the issue
described causes 2 identical SCEV expressions to have different order
of operands and therefore compare not equal, which in its turn
prevents LoadStoreVectorizer from vectorizing a pair of consecutive
loads.

On a larger example (the source of the test attached, which is a
bugpoint) I have seen even weirder behavior: adding a constant to an
existing SCEV changes the order of the existing terms, for instance,
getAddExpr(1, ((A * B) + (C * D))) returns (1 + (C * D) + (A * B)).

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

llvm-svn: 340777

Set line endings to Windows on MSBuild files.

Normally we force Unix line endings in the repository, but since these are Windows files which are consumed by Microsoft tools that we don't have the source of, we should probably err on the side of caution and force CRLF.

llvm-svn: 340776

[X86] Reverse the check prefixes in the test added in r340774.

The 32-bit and 64-bit checks were reversed.

llvm-svn: 340775

[X86] Add test cases to show current codegen of v2i32 div/rem in 32-bit and 64-bit modes

In particular this shows that we end up using libcalls in 32-bit mode even for division by constant.

llvm-svn: 340774

[x86] add tests for possibly avoiding scalar->vector move; NFC

llvm-svn: 340773

[OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading

Summary: When offloading to a device and using the powerpc64le version of the auxiliary triple, the _CALL_ELF macro is not set correctly to 2 resulting in the attempt to include a header that does not exist. This patch fixes this problem.

Reviewers: Hahnfeld, ABataev, caomhin

Reviewed By: Hahnfeld

Subscribers: guansong, cfe-commits

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

llvm-svn: 340772

[OpenMP][Fix] Conditional compilation leaves variables unused

Summary: Prevent variables from being left unused by conditional compilation.

Reviewers: ABataev, grokos, Hahnfeld, caomhin, protze.joachim

Reviewed By: Hahnfeld

Subscribers: guansong, openmp-commits

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

llvm-svn: 340771

[PPC] Remove Darwin support from POWER backend.
This patch removes uses of the Darwin ABI for PowerPC related test cases. This
is the first step in removing Darwin support from the POWER backend.

clang/test/CodeGen/darwin-ppc-varargs.c  was deleted because it was a darwin/ppc
specific test case.

All other tests were updated to remove the darwin/ppc specific invocation.

Phabricator Review: https://reviews.llvm.org/D50989.

llvm-svn: 340770

[lsan] Check that leak sanitizer works in the forked process

Regression test for PR38698

llvm-svn: 340769

[llvm-mca] Remove unused include. NFC

llvm-svn: 340768

[OpenMP][libomptarget] rework of fatal error reporting

Summary:
Removed the function that used a lock and varargs
Used the same mechanism as for debug messages

Reviewers: ABataev, gtbercea, grokos, Hahnfeld

Reviewed By: gtbercea, Hahnfeld

Subscribers: mikerice, ABataev, RaviNarayanaswamy, guansong, openmp-commits

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

llvm-svn: 340767

DAG: Check transformed type for forming fminnum/fmaxnum from vselect

Follow up to r340655 to fix vector types which are split.

llvm-svn: 340766

[Sema/Attribute] Make types declared with address_space an AttributedType

Currently an address_space is stored in a qualifier. This makes any type
declared with an address_space attribute in the form
`__attribute__((address_space(1))) int 1;` be wrapped in an AttributedType.

This is for a later patch where if `address_space` is declared in a macro,
any diagnostics that would normally print the address space will instead dump
the macro name. This will require saving any macro information in the
AttributedType.

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

llvm-svn: 340765

[sanitizer][fuzzer] Transition back to ZX_TIME_INFINITE

Now that all Zircon calls have been transitioned to take time as signed
value, we can transition back to ZX_TIME_INFINITE, undoing the change
made in r337802.

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

llvm-svn: 340764

MachineVerifier: Fix assert on implicit virtreg use

If the liveness of a physical register was invalid, this
was attempting to iterate the subregisters of all register
uses of the instruction, which would assert when it
encountered an implicit virtual register operand.

llvm-svn: 340763

LangRef: Clarify expected sNaN behavior for minnum/maxnum

This matches the de-facto behavior based on constant folding
and the default lowering to fmin/fmax.

llvm-svn: 340762

[PowerPC][MC] Support expressions in getMemRIX16Encoding.

Loosens an assert in getMemRIX16Encoding that restricts DQ-form instructions to
using an immediate, so that we can assemble instructions like lxv/stxv where the
offset is an expression.

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

llvm-svn: 340761

[NVPTX] Implement isLegalToVectorizeLoadChain

This lets LSV nicely split up underaligned chains.

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

llvm-svn: 340760

Cleanup after rL340729

llvm-svn: 340759

Revert "[lsan] Do not check for leaks in the forked process"

Users need leak reports in forks.

This reverts commit r334036.

llvm-svn: 340758

[X86] When lowering v32i8 MULHS/MULHU, shuffle after the PACKUS rather than before.

We're using a 256-bit PACKUS to do the truncation, but that instruction operates on 128-bit lanes. So previously we shuffled first to rearrange the lanes. But that requires 2 shuffles. Instead we can shuffle after the PACKUS using a single VPERMQ. This matches what our normal LowerTRUNCATE code does when it uses PACKUS.

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

llvm-svn: 340757

[X86] Add support for matching paddus patterns where one of the vectors is a constant.

InstCombine mucks these up a bit. So we need to do some additional pattern matching to fix it. There are a still a few special cases not handled, but this covers the general case.

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

llvm-svn: 340756

[llvm-mca] Introduce the llvm-mca library and organize the directory accordingly. NFC.

Summary:
This patch introduces llvm-mca as a library.  The driver (llvm-mca.cpp), views, and stats, are not part of the library.
Those are separate components that are not required for the functioning of llvm-mca.

The directory has been organized as follows:
All library source files now reside in:
  - `lib/HardwareUnits/` - All subclasses of HardwareUnit (these represent the simulated hardware components of a backend).
      (LSUnit does not inherit from HardwareUnit, but Scheduler does which uses LSUnit).
  - `lib/Stages/` - All subclasses of the pipeline stages.
  - `lib/` - This is the root of the library and contains library code that does not fit into the Stages or HardwareUnit subdirs.

All library header files now reside in the `include` directory and mimic the same layout as the `lib` directory mentioned above.

In the (near) future we would like to move the library (include and lib) contents from tools and into the core of llvm somewhere.
That change would allow various analysis and optimization passes to make use of MCA  functionality for things like cost modeling.

I left all of the non-library code just where it has always been, in the root of the llvm-mca directory.
The include directives for the non-library source file have been updated to refer to the llvm-mca library headers.
I updated the llvm-mca/CMakeLists.txt file to include the library headers, but I made the non-library code
explicitly reference the library's 'include' directory.  Once we eventually (hopefully) migrate the MCA library
components into llvm the include directives used by the non-library source files will be updated to point to the
proper location in llvm.

Reviewers: andreadb, courbet, RKSimon

Reviewed By: andreadb

Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits

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

llvm-svn: 340755

[llvm-mca] Remove unused method. NFC.

llvm-svn: 340754

[lit, python] Remove quotes around %python in cache.ll

Summary: We needed quotes around %python before to make python work correctly (on Windows) if the path contains spaces. I recently made a change so that %python now inherently has quotes, so now adding quotes around %python makes the test fail because the quotes cancel each other.

Reviewers: asmith, inglorion

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

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

llvm-svn: 340753

Mark P0556 as 'in progress'

llvm-svn: 340752

Use a lambda for calls to ::open in RetryAfterSignal

In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing
compile errors of RetryAfterSignal due to overload resolution. Wrapping
the call in a lambda avoids this.

Based on a patch by Chih-Wei Huang <cwhuang@linux.org.tw>!

llvm-svn: 340751

[WebAssembly] Added default stack-only instruction mode for MC.

Summary:
Made it convert from register to stack based instructions, and removed the registers.
Fixes to related code that was expecting register based instructions.
Added the correct testing flag to all tests, depending on what the
format they were expecting so far.
Translated one test to stack format as example: reg-stackify-stack.ll

tested:
llvm-lit -v `find test -name WebAssembly`
unittests/MC/*

Reviewers: dschuff, sunfish

Subscribers: sbc100, jgravelle-google, eraman, aheejin, llvm-commits, jfb

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

llvm-svn: 340750

[docs] Mention clangd-dev in clangd documentation

Since the clangd-dev is intended to be the place for clangd-related
discussions, we should point new users to this mailing list while
probably mentioning cfe-dev, too.

Reviewed by: ioeric

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

llvm-svn: 340749

Let the CompilerInstance create our clang ASTContext

Summary:
Now that we moved the BuiltinContext and SelectorTable to the
CompilerInstance, we can also get rid of manually creating our
own ASTContext, but just use the one from the CompilerInstance
(which will be created with the same settings).

Reviewers: vsk, aprantl, davide

Reviewed By: davide

Subscribers: lldb-commits

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

llvm-svn: 340748

Disable use-color if the output stream is not a terminal with color support.

Summary:
LLDB currently only checks the output terminal for color support by looking
at the `TERM` environment variable and comparing it to `"dumb"`. This causes that
when running LLDB on a CI node, the syntax highlighter will not be deactivated by
LLDB and the output log is filled with color codes (unless the terminal emulator
actually exposes itself as dumb).

This patch now relies on the LLVM code for detecting color support which is more
reliable. We now also correctly actually initialize the `m_supports_colors` variable in `File`.
`m_supports_colors` was so far uninitialized, but the code path that uses `m_supports_colors`
was also dead so the sanitizers didn't sound an alarm.

The old check that compares `TERM` is not removed by this patch as the new LLVM code
doesn't seem to handle this case (and it's a good thing to check for "dumb" terminals).

Reviewers: aprantl, javed.absar

Reviewed By: aprantl

Subscribers: kristof.beyls, abidh, lldb-commits

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

llvm-svn: 340747

[llvm-mca] Improved report generated by the SchedulerStatistics view.

Before this patch, the SchedulerStatistics only printed the maximum number of
buffer entries consumed in each scheduler's queue at a given point of the
simulation.

This patch restructures the reported table, and adds an extra field named
"Average number of used buffer entries" to it.
This patch also uses different colors to help identifying bottlenecks caused by
high scheduler's buffer pressure.

llvm-svn: 340746

[OpenMP][Fix] Ensure comparison between unsigned values.

Summary: Ensure the values being compared are both unsigned.

Reviewers: ABataev, Hahnfeld, caomhin, grokos, AndreyChurbanov

Reviewed By: AndreyChurbanov

Subscribers: AndreyChurbanov, guansong, openmp-commits

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

llvm-svn: 340745

fix comment typo

llvm-svn: 340744

fix comment typo

llvm-svn: 340743

fix comment typo

llvm-svn: 340742

[SelectionDAG] add helper query for binops; NFC

We will also use this in a planned enhancement for vector insertelement.

llvm-svn: 340741

[PowerPC] Revert commit r339779

This commit has caused failures in some internal benchmarks. Temporarily
reverting this patch until the issue can be diagnosed and fixed.

llvm-svn: 340740

[ELF][HEXAGON] Add R_HEX_11/10/9_X support

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

llvm-svn: 340739

Handle identifying AMDGPU bitcode files

llvm-svn: 340738

[X86] Adding the test pointing to the fail case of D45653

Summary:
This commit adds the case of tail calling a sret function from a non-sret
function when both functions have the C calling convention.

llvm-svn: 340737

[Sparc] Avoid writing outside array in applyFixup

Summary: If an object file ends with a relocation that is smaller
than 4 bytes we will write outside the Data array and trigger an
"Invalid index" assertion.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

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

llvm-svn: 340736

[NFC][X86] Fix `sibcall.ll` formatting

Summary:
Remove unnecessary lines from `sibcall.ll` and rename labels according
to @RKSimon's recommendations in the D45653 conversation.

llvm-svn: 340735

[PowerPC] Recommit r340016 after fixing the reported issue

The internal benchmark failure reported by Google was due to a missing
check for the result type for the sign-extend and shift DAG. This commit
adds the check and re-commits the patch.

llvm-svn: 340734

[Sparc] Add support for the cycle counter available in GR740

Summary: The GR740 provides an up cycle counter in the registers ASR22
and ASR23. As these registers can not be read together atomically we only
use the value of ASR23 for llvm.readcyclecounter(). The ASR23 register
holds the 32 LSBs of the up-counter.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

Subscribers: jfb, fedor.sergeev, jrtc27, llvm-commits

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

llvm-svn: 340733

[NFC] Try to make buildbot happy about virtual destructors

llvm-svn: 340732

[clangd] Use TRUE iterator instead of complete posting list

Stop using `$$$` (empty) trigram and generating a posting list with all
items. Since TRUE iterator is already implemented and correctly inserted
when there are no real trigram posting lists, this is a valid
transformation.

Benchmarks show that this simple change allows ~30% speedup on dataset
of real completion queries.

Before

```
-------------------------------------------------------
Benchmark                Time           CPU Iterations
-------------------------------------------------------
DexAdHocQueries    5640321 ns    5640265 ns        120
DexRealQ         939835603 ns  939830296 ns          1
```

After

```
-------------------------------------------------------
Benchmark                Time           CPU Iterations
-------------------------------------------------------
DexAdHocQueries    3452014 ns    3451987 ns        203
DexRealQ         667455912 ns  667455750 ns          1
```

Reviewed by: ilya-biryukov

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

llvm-svn: 340729

[NFC] Split logic of ImplicitControlFlowTracking to allow generalization

We have a class `ImplicitControlFlowTracking` which allows us to keep track of
instructions that can abnormally exit and answer queries like "whether or not
there is side-exiting instruction above this instruction in its block".

We may want to have the similar tracking for other types of "special" instructions,
for example instructions that write memory.

This patch separates ImplicitControlFlowTracking into two classes, isolating all
general logic not related to implicit control flow into its parent class. We can
later make another child of this class to keep track of instructions that write
memory.

The motivation for that is that we want to make these checks efficiently in the
patch https://reviews.llvm.org/D50891.

NOTE: The naming of the parent class is not super cool, but the other options we
have are hardly better. Please feel free to rename it as NFC if you think you've
found a more informative name for it.

Differential Revision: https://reviews.llvm.org/D50954
Reviewed By: fedor.sergeev

llvm-svn: 340728

Try to fix this clang driver test case after r340709.

If any of the bots complain about this, I'll just revert. This test case
is essentially trying to test the exact change made, but I think this
matches the intent of the patch in question.

llvm-svn: 340727

[COFF] Support MinGW automatic dllimport of data

Normally, in order to reference exported data symbols from a different
DLL, the declarations need to have the dllimport attribute, in order to
use the __imp_<var> symbol (which contains an address to the actual
variable) instead of the variable itself directly. This isn't an issue
in the same way for functions, since any reference to the function without
the dllimport attribute will end up as a reference to a thunk which loads
the actual target function from the import address table (IAT).

GNU ld, in MinGW environments, supports automatically importing data
symbols from DLLs, even if the references didn't have the appropriate
dllimport attribute. Since the PE/COFF format doesn't support the kind
of relocations that this would require, the MinGW's CRT startup code
has an custom framework of their own for manually fixing the missing
relocations once module is loaded and the target addresses in the IAT
are known.

For this to work, the linker (originall in GNU ld) creates a list of
remaining references needing fixup, which the runtime processes on
startup before handing over control to user code.

While this feature is rather controversial, it's one of the main features
allowing unix style libraries to be used on windows without any extra
porting effort.

Some sort of automatic fixing of data imports is also necessary for the
itanium C++ ABI on windows (as clang implements it right now) for importing
vtable pointers in certain cases, see D43184 for some discussion on that.

The runtime pseudo relocation handler supports 8/16/32/64 bit addresses,
either PC relative references (like IMAGE_REL_*_REL32*) or absolute
references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32,
IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a
relocation against the corresponding IAT slot. For the absolute references,
a normal base relocation is created, to update the embedded address
in case the image is loaded at a different address.

The list of runtime pseudo relocations contains the RVA of the
imported symbol (the IAT slot), the RVA of the location the relocation
should be applied to, and a size of the memory location. When the
relocations are fixed at runtime, the difference between the actual
IAT slot value and the IAT slot address is added to the reference,
doing the right thing for both absolute and relative references.

With this patch alone, things work fine for i386 binaries, and mostly
for x86_64 binaries, with feature parity with GNU ld. Despite this,
there are a few gotchas:
- References to data from within code works fine on both x86 architectures,
  since their relocations consist of plain 32 or 64 bit absolute/relative
  references. On ARM and AArch64, references to data doesn't consist of
  a plain 32 or 64 bit embedded address or offset in the code. On ARMNT,
  it's usually a MOVW+MOVT instruction pair represented by a
  IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of
  the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR
  instruction pair with an even more complex encoding, storing a PC
  relative address (with a range of +/- 4 GB). This could theoretically
  be remedied by extending the runtime pseudo relocation handler with new
  relocation types, to support these instruction encodings. This isn't an
  issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64.
- For x86_64, if references in code are encoded as 32 bit PC relative
  offsets, the runtime relocation will fail if the target turns out to be
  out of range for a 32 bit offset.
- Fixing up the relocations at runtime requires making sections writable
  if necessary, with the VirtualProtect function. In Windows Store/UWP apps,
  this function is forbidden.

These limitations are addressed by a few later patches in lld and
llvm.

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

llvm-svn: 340726

[COFF] Expose an easier helper function for getting names for relocation types

The existing method is protected, and requires using DataRefImpl
and SmallVector.

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

llvm-svn: 340725

[Sparc] Custom bitcast between f64 and v2i32

Summary:
Currently bitcasting constants from f64 to v2i32 is done by storing the
value to the stack and then loading it again. This is not necessary, but
seems to happen because v2i32 is a valid type for Sparc V8. If it had not
been legal, we would have gotten help from the type legalizer.

This patch tries to do the same work as the legalizer would have done by
bitcasting the floating point constant and splitting the value up into a
vector of two i32 values.

Reviewers: venkatra, jyknight

Reviewed By: jyknight

Subscribers: glaubitz, fedor.sergeev, jrtc27, llvm-commits

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

llvm-svn: 340723

[RISCV] atomic_store_nn have a different layout to regular store

We cannot directy reuse the patterns of StPat because for some reason the store
DAG node and the atomic_store_nn DAG nodes put the ptr and the value in
different positions. Currently we attempt to store the address to an address
formed by the value.

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

llvm-svn: 340722

Fix this file to have the necessary standard library includes and use
the `std::` namespace. Should fix a number of build bots as well.

llvm-svn: 340721

[X86] Cleanup the LowerMULH code by hoisting some commonalities between the vXi32 and vXi8 handling. NFCI

vXi32 support was recently moved from LowerMUL_LOHI to LowerMULH.

This commit shares the getOperand calls, switches both to use common IsSigned flag, and hoists the NumElems/NumElts variable.

llvm-svn: 340720

[X86] Add intrinsics for kand/kandn/knot/kor/kxnor/kxor with 8, 32, and 64-bit mask registers.

This also adds a second intrinsic name for the 16-bit mask versions.

These intrinsics match gcc and icc. They just aren't published in the Intel Intrinsics Guide so I only recently found they existed.

llvm-svn: 340719

[X86] Remove min_vector_width 512 from some intrinsics that operate only on k-registers.

llvm-svn: 340718

[X86] Rename __DEFAULT_FN_ATTRS to a__DEFAULT_FN_ATTRS512 in avx512dqintrin.h and avx512bwintrin.h.

This is preparation for adding removing min_vector_width 512 from some intrinsics.

llvm-svn: 340717

Rename a function to follow the LLVM coding style.

llvm-svn: 340716

[COFF] Check the instructions in ARM MOV32T relocations

For this relocation, which applies to two consecutive instructions,
it's plausible that the second instruction might not actually be
the right one.

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

llvm-svn: 340715

[X86] Undef __DEFAULT_FN_ATTRS in avx512fintrin.h.

Fixes test failure after r340713

llvm-svn: 340714

[X86] Don't set min_vector_width to 512 on intrinsics that only operate on k registers.

llvm-svn: 340713

[Xray] Darwin - Enable in the driver side

Reviewers: dberris

Reviered By: dberris

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

llvm-svn: 340712

[MS Demangler] Add virtual destructor.

Silence -Wnon-virtual-dtor.

llvm-svn: 340711

[MS Demangler] Re-write the Microsoft demangler.

This is a pretty large refactor / re-write of the Microsoft
demangler.  The previous one was a little hackish because it
evolved as I was learning about all the various edge cases,
exceptions, etc.  It didn't have a proper AST and so there was
lots of custom handling of things that should have been much
more clean.

Taking what was learned from that experience, it's now
re-written with a completely redesigned and much more sensible
AST.  It's probably still not perfect, but at least it's
comprehensible now to someone else who wants to come along
and make some modifications or read the code.

Incidentally, this fixed a couple of bugs, so I've enabled
the tests which now pass.

llvm-svn: 340710

[Driver] Change MipsLinux default linker from "lld" to "ld.lld"

Reviewers: kzhuravl, atanasyan

Reviewed By: atanasyan

Subscribers: sdardis, arichardson, jrtc27, atanasyan, cfe-commits

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

llvm-svn: 340709

[X86] Correct the cost of (v4i32 (fptoui (v4f64))) under AVX512F.

Summary: This was inheriting the cost from the AVX table, but should be legal under AVX512.

Reviewers: RKSimon

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 340708

[X86] Add FeatureCMOV explicitly to all CPUs that support it. Remove FeatureCMOV implication from Feature64Bit and FeatureSSE1

Summary:
Previously most CPUs inherited cmov support through Feature64Bit(or FeatureCMPXCHG16HB implying Feature64Bit) or FeatureSSE1.

This has the surprising side effect that -mattr=-cmov causes an assert to fire in 64-bit mode because it clears the Feature64Bit. Or in 32-bit mode, -mattr=-cmov disables any sse/avx features which seems surprising.

This patch removes the implication and instead updates hasCMOV in X86Subtarget to check SSE1 or is64Bit in addition to the regular cmov flag. This should keep most things working the way they did before. I don't believe there is a way to specific "-cmov" directly from clang so this should only effect our lower level tools.

This does stop -mattr=cx16(cmpxchg16b) from implying cmov is enabled via the 64bit flag as you can see from one of the changed tests. But that was a 32-bit test so I don't know why it enabled cx16 anyway.

For the other test I had to add -sse to override the new sse check in hasCMOV.

Reviewers: RKSimon, DavidKreitzer, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits, jfb

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

llvm-svn: 340707

[X86] Add FeatureCMOV to athlon and athlon-tbird cpus.

Summary: This matches gcc and one cpuid dump I found online. Given that these are considered 7th generation x86 CPU it seems likely they support cmov since cmov was added by Intel in their 6th generation.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 340706

[SelectionDAG][x86] turn insertelement into undef with variable index into splat

I noticed this along with the patterns in D51125, but when the index is variable,
we don't convert insertelement into a build_vector.

For x86, that means these get expanded at legalization time into the loading/spilling
code that we see in the tests. I think it's always better to avoid going to memory on
these, and we get the optimal 'broadcast' if it's available.

I suspect other targets may want to look at enabling the hook. AArch64 and AMDGPU have
regression tests that would be affected (although I did not check what would happen in
those cases). In the most basic cases shown here, AArch64 would probably do much
better with a splat.

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

llvm-svn: 340705

[ORC] Remove a workaround for systems lacking 8-byte atomics.

SymbolStringPool ref counts are now size_t, rather than uint64_t, so I do not
think this is necessary any more.

llvm-svn: 340704

[ORC] Do not include non-global symbols in getObjectSymbolFlags.

Private symbols are not visible outside the object file, and so not defined by
the object file from ORC's perspective.

No test case yet. Ideally this would be a unit test parsing a checked-in binary,
but I am not aware of any way to reference the LLVM source root from a unit
test.

llvm-svn: 340703

Replace fancy use of initializer lists with simple functions that return
vectors, and move this test code into an anonymous namespace.

Hoping that this will avoid hitting an MSVC bug that causes it to crash
and burn pretty spectacularly. Also, this degree of clever use of
initializer lists seems somewhat questionable in general. ;]

llvm-svn: 340702

[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.

This is a bit awkward in a handful of places where we didn't even have
an instruction and now we have to see if we can build one. But on the
whole, this seems like a win and at worst a reasonable cost for removing
`TerminatorInst`.

All of this is part of the removal of `TerminatorInst` from the
`Instruction` type hierarchy.

llvm-svn: 340701

Avoid specializing a variadic member template in a way that seems to not
agree with MSVC.

There isn't actually a need for specialization here as we can write the
code generically and just have a test that will fold away as a constant.

llvm-svn: 340700

[IR] Sink `isExceptional` predicate to `Instruction`, rename it to
`isExceptionalTermiantor` and implement it for opcodes as well following
the common pattern in `Instruction`.

Part of removing `TerminatorInst` from the `Instruction` type hierarchy
to make it easier to share logic and interfaces between instructions
that are both terminators and not terminators.

llvm-svn: 340699

[IR] Begin removal of TerminatorInst by removing successor manipulation.

The core get and set routines move to the `Instruction` class. These
routines are only valid to call on instructions which are terminators.

The iterator and *generic* range based access move to `CFG.h` where all
the other generic successor and predecessor access lives. While moving
the iterator here, simplify it using the iterator utilities LLVM
provides and updates coding style as much as reasonable. The APIs remain
pointer-heavy when they could better use references, and retain the odd
behavior of `operator*` and `operator->` that is common in LLVM
iterators. Adjusting this API, if desired, should be a follow-up step.

Non-generic range iteration is added for the two instructions where
there is an especially easy mechanism and where there was code
attempting to use the range accessor from a specific subclass:
`indirectbr` and `br`. In both cases, the successors are contiguous
operands and can be easily iterated via the operand list.

This is the first major patch in removing the `TerminatorInst` type from
the IR's instruction type hierarchy. This change was discussed in an RFC
here and was pretty clearly positive:
http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html

There will be a series of much more mechanical changes following this
one to complete this move.

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

llvm-svn: 340698

[MIPS GlobalISel] Legalize i8 and i16 add

Legalize G_ADD for types smaller than i32.
LegalizationArtifactCombiner replaces extend instructions with appropriate
bitwise instructions.

Patch by Petar Avramovic.

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

llvm-svn: 340697

[index] Introduce 'ProtocolInterface' as part of SymbolPropertySet

This is useful to directly infer that a method or property is from a protocol interface
at the point of the symbol occurrences.

llvm-svn: 340696

[X86] Fix typo in comment, expect->except. NFC

llvm-svn: 340695

[X86] Add test cases for D50952, paddus patterns involving constants. NFC

llvm-svn: 340694

[ELF][HEXAGON] Add R_HEX_B13_PCREL relocation support

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

llvm-svn: 340693

[ELF][HEXAGON] Add R_HEX_B9_PCREL and R_HEX_B9_PCREL_X relocation support

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

llvm-svn: 340692

[C-API][DIBuilder] Use NameLen in LLVMDIBuilderCreateParameterVariable

Summary: NameLen wasn't being used and caused the parameters in gdb to very long, in my case, crashes in others. Please also perform the correct magical incarnations to have this be applied to the LLVM 7 branch.

Reviewers: whitequark, CodaFi

Reviewed By: CodaFi

Subscribers: llvm-commits

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

llvm-svn: 340691

[X86] Replace support for vXi32 SMUL_LOHI/UMUL_LOHI with MULHS/MULHU support instead.

Summary:
The only time vector SMUL_LOHI/UMUL_LOHI nodes are created is during division/remainder lowering. If its created before op legalization, generic DAGCombine immediately turns that SMUL_LOHI/UMUL_LOHI into a MULHS/MULHU since only the upper half is used. That node will stick around through vector op legalization and will be turned back into UMUL_LOHI/SMUL_LOHI during op legalization. It will then be custom lowered by the X86 backend. Due to this two step lowering the vector shuffles created by the custom lowering get legalized after their inputs rather than before. This prevents the shuffles from being combined with any build_vector of constants.

This patch uses changes vXi32 to use MULHS/MULHU instead. This is what the later DAG combine did anyway. But by skipping the change back to UMUL_LOHI/SMUL_LOHI we lower it before any constant BUILD_VECTORS. This allows the vector_shuffle creation to constant fold with the build_vectors. This accounts for the test changes here.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 340690

[SelectionDAG][X86] Reorder the operands the MaskedStoreSDNode to put the value first.

Summary:
Previously the value being stored is the last operand in SDNode. This causes the type legalizer to visit the mask operand before the value operand. The type legalizer was more complicated because of this since we want the type of the value to drive the decisions.

This patch moves the value to be the first operand so we visit it first during type legalization. It also simplifies the type legalization code accordingly.

X86 is currently the only in tree target that uses this SDNode. Not sure if there are any users out of tree.

Reviewers: RKSimon, delena, hfinkel, eli.friedman

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 340689

[X86] Make sure type is a vector before calling VT.getVectorNumElements() in combineLoopMAddPattern

Fixes PR38700.

llvm-svn: 340688

Fix -Wunused-function warning. NFCI.

llvm-svn: 340687

Remove superfluous semicolon. NFCI.

llvm-svn: 340686

[x86] try harder to use broadcast to load a scalar into vector reg

This is a preliminary step for a preliminary step for D50992.
I noticed that x86 often misses chances to load a scalar directly
into a vector register.

So this patch is just allowing more of those cases to match a
broadcast op in lowerBuildVectorAsBroadcast(). The old code comment
said it doesn't make sense to use a broadcast when we're loading a
single element and everything else is undef, but I think that's the
best case in the improved tests in insert-loaded-scalar.ll. We avoid
scalar-to-vector-register move and/or less efficient shuffling.

Note that there are some existing types that were already producing
a broadcast, but that happens semi-accidentally. Ie, it's not
happening as part of lowerBuildVectorAsBroadcast(). The build vector
gets expanded into load + shuffle, and then shuffle lowering produces
the broadcast.

Description of the other test diffs:
1. avx-basic.ll - replacing load+shufle is a win.
2. sse3-avx-addsub-2.ll - vmovddup vs. vbroadcastss is neutral
3. sse41.ll - don't care - we convert that intrinsic to generic IR now, so this test is deprecated
4. vector-shuffle-128-v8.ll / vector-shuffle-256-v16.ll - pshufb alternatives with an extra instruction are not obviously bad

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

llvm-svn: 340685

[AMDGPU] Add support for multi-dword s.buffer.load intrinsic

Summary:
Patch by Marek Olsak and David Stuttard, both of AMD.

This adds a new amdgcn intrinsic supporting s.buffer.load, in particular
multiple dword variants. These are convenient to use from some front-end
implementations.

Also modified the existing llvm.SI.load.const intrinsic to common up the
underlying implementation.

This modification also requires that we can lower to non-uniform loads correctly
by splitting larger dword variants into sizes supported by the non-uniform
versions of the load.

V2: Addressed minor review comments.
V3: i1 glc is now i32 cachepolicy for consistency with buffer and
    tbuffer intrinsics, plus fixed formatting issue.
V4: Added glc test.

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits

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

Change-Id: I83a6e00681158bb243591a94a51c7baa445f169b
llvm-svn: 340684

[InstCombine] add tests for shuffle+binop transform; NFC

llvm-svn: 340683

[X86] Make requested test changes from D50636

The tests were relying on X / X -> 1 and X % X -> 0 combines not happening in the DAG.

llvm-svn: 340682

[CUDA/OpenMP] Define only some host macros during device compilation

When compiling CUDA or OpenMP device code Clang parses header files
that expect certain predefined macros from the host architecture. To
make this work the compiler passes the host triple via the -aux-triple
argument and (until now) pulls in all macros for that "auxiliary triple"
unconditionally.

However this results in defines like __SSE_MATH__ that will trigger
inline assembly making use of the "advertised" target features. See
the discussion of D47849 and PR38464 for a detailed explanation of
the encountered problems.

Instead of blacklisting "known bad" examples this patch starts adding
defines that are needed for certain headers like bits/wordsize.h and
bits/mathinline.h.
The disadvantage of this approach is that it decouples the definitions
from their target toolchain. However in my opinion it's more important
to keep definitions for one header close together. For one this will
include a clear documentation why these particular defines are needed.
Furthermore it simplifies maintenance because adding defines for a new
header or support for a new aux-triple only needs to touch one piece
of code.

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

llvm-svn: 340681

[CodeGen] Set FrameSetup/FrameDestroy on BUNDLE instructions

Summary:
If any of the bundled instructions are marked as FrameSetup
or FrameDestroy, then that property is set on the BUNDLE
instruction as well.

As long as the scheduler/packetizer aren't mixing
prologue/epilogue instructions (i.e. all the bundled
instructions have the same property) then this simply gives
the bundle the correct property (so when using a bundle
iterator in late passes a bundle will be correctly identified
as FrameSetup/FrameDestroy).

When for example bundling a mix of FrameSetup instructions
with non-FrameSetup instructions it could be discussed if
the bundle should have the property or not. The choice here
has been to set these properties on the BUNDLE instruction if
any of the bundled instructions have the property set.

Reviewers: #debug-info, kparzysz

Reviewed By: kparzysz

Subscribers: vsk, thegameg, llvm-commits

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

llvm-svn: 340680

[LiveDebugVariables] Avoid faulty addDefsFromCopies in computeIntervals

Summary:
When computeIntervals is looking through COPY instruction to
extend the location mapping for a debug variable it did not
handle subregisters correctly.

For example
    DBG_VALUE debug-use %0.sub_8bit_hi, ...
    %1:gr16 = COPY %0
was transformed into
    DBG_VALUE debug-use %0.sub_8bit_hi, ...
    %1:gr16 = COPY %0
    DBG_VALUE debug-use %1, ...
So the subregister index was missing in the added DBG_VALUE.

As long as the subreg refered to the least significant bits
of the superreg, then I guess we could get the correct
result in a debugger even when referring to the superreg.
But as in the example above when the subreg refers to other
parts of the superreg, then debuginfo would be incorrect.

I'm not sure exactly how to fix this properly, so this patch
just avoids looking through the COPY when there is a subreg
involved (for more info, see the FIXME added in the code).

Reviewers: rnk, aprantl

Reviewed By: aprantl

Subscribers: JDevlieghere, llvm-commits

Tags: #debug-info

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

llvm-svn: 340679