[MS ABI] Mangle unnamed empty enums (PR37723)

Differential Revision: https://reviews.llvm.org/D47875 — hans / ViewSVN
[X86] Add encoding tests for avx5124fmaps and avx5124vnni instructions.

I forgot to git add these in r333812 — ctopper / ViewSVN
[X86] Add test files for upgrade of vbmi2 expand load and compress store intrinsics that was done in r334381. — ctopper / ViewSVN
[X86] Remove masking from dbpsadbw builtins, use select builtin instead. — ctopper / ViewSVN
[X86] Remove masking from dbpsadbw intrinsics, use select in IR instead. — ctopper / ViewSVN
[Sparc] Add support for 13-bit PIC

Summary: When compiling with -fpic, in contrast to -fPIC, use only the
immediate field to index into the GOT. This saves space if the GOT is
known to be small. The linker will warn if the GOT is too large for
this method.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

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

Differential Revision: https://reviews.llvm.org/D47136 — dcederman / ViewSVN
[CodeView] Omit forward references for unnamed structs and unions

Codeview references to unnamed structs and unions are expected to refer to the
complete type definition instead of a forward reference so Visual Studio can
resolve the type properly.

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

— bwyma / ViewSVN
[X86] Remove and autoupgrade the expandload and compressstore intrinsics.

We use the target independent intrinsics now. — ctopper / ViewSVN
[TableGen] Make better use of std::map::emplace and emplace construct the object in the map rather than moving it into it. Remove a use std::map::find by remembering the return from emplace. — ctopper / ViewSVN
[TableGen] Combine two constructors by taking vectors by value instead of trying to support combininations for rvalue and lvalue references. — ctopper / ViewSVN
[DAGCombiner] match vector compare and select sizes with extload operand (PR37427)

This patch started off much more general and ambitious, but it's been a nightmare
seeing all the ways x86 vector codegen can go wrong.

So the code is still structured to allow extending easily, but it's currently
limited in several ways:

1. Only handle cases with an extending load.
2. Only handle cases with a zero constant compare.
3. Ignore setcc with vector bitmask (SetCCWidth != 1) - so AVX512 should be unaffected.

The motivating case from PR37427:
https://bugs.llvm.org/show_bug.cgi?id=37427
...is the 1st test, and that shows the expected win - we eliminated the unnecessary
intermediate cast.

There's a clear regression in the last test (sgt_zero_fp_select) because we longer
recognize a 'SHRUNKBLEND' opportunity. I think that general problem is also present
in sgt_zero, so I'll try to fix that in a follow-up. We need to match a sign-bit
setcc from a sign-extended operand and remove it.

Differential Revision: https://reviews.llvm.org/D47330
— spatel / ViewSVN
[X86] Miscellaneous fixes to get the load folding table generator to work again. — ctopper / ViewSVN
Revert r334374 [TableGen] Move some shared_ptrs to avoid unnecessary copies (NFC).

This breaks some builders.
— fhahn / ViewSVN
Attempt 3: Resubmit "[Support] Expose flattenWindowsCommandLine."

I took some liberties and quoted fewer characters than before,
based on an article from MSDN which says that only certain characters
cause an arg to require quoting. This seems to be incorrect, though,
and worse it seems to be a difference in Windows version. The bot
that fails is Windows 7, and I can't reproduce the failure on Win
10. But it's definitely related to quoting and special characters,
because both tests that fail have a * in the argument, which is one
of the special characters that would cause an argument to be quoted
before but not any longer after the new patch.

Since I don't have Win 7, all I can do is just guess that I need to
restore the old quoting rules. So this patch does that in hopes that
it fixes the problem on Windows 7. — zturner / ViewSVN
[TableGen] Move some shared_ptrs to avoid unnecessary copies (NFC).

Those changes were suggested post-commit for D47463.
— fhahn / ViewSVN
Revert rL334371 / D47980: "[InstCombine] Fold (x << y) >> y -> x & (-1 >> y)"

test/Transforms/InstCombine/AMDGPU/amdgcn-intrinsics.ll broke,
and i did not notice because i did not build that backend. — lebedevri / ViewSVN
[InstCombine] Fold (x >> y) << y -> x & (-1 << y)

Summary:
We already do it for matching splat constants, but not just values.

Further improvements for non-matching splat constants, as noted in
https://reviews.llvm.org/D46760#1123713 will be needed,
but i'd prefer to do that as a follow-up.

https://bugs.llvm.org/show_bug.cgi?id=37603
https://rise4fun.com/Alive/cplX
https://rise4fun.com/Alive/0HF

Reviewers: spatel, craig.topper

Reviewed By: spatel

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D47981 — lebedevri / ViewSVN
[InstCombine] Fold (x << y) >> y -> x & (-1 >> y)

Summary:
We already do it for splat constants, but not just values.
Also, undef cases are mostly non-functional.

https://bugs.llvm.org/show_bug.cgi?id=37603
https://rise4fun.com/Alive/cplX

Reviewers: spatel, craig.topper

Reviewed By: spatel

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D47980 — lebedevri / ViewSVN
[NFC][InstCombine] Revisit tests for D47980 / D47981 once more. — lebedevri / ViewSVN
[debuginfo-tests] Always use the system python to invoke llgdb.py.

/usr/bin/env is recommended as a cross-platform way to find python. But:
- we're only using lldb on darwin, where we know python (or at least,
the xcrun-style shortcut) is in /usr/bin/
- the python interpreter in LLDB comes from /S/L/F:
$ otool -L Contents/SharedFrameworks/LLDB.framework/LLDB | grep Python
/System/Library/Frameworks/Python.framework/Versions/2.7/Python

so when we use the lldb python module, it calls into the swig/python
support in the lldb framework, and if there's a mismatch between the
interpreter and the linked python, weird things occur.

In theory, I believe this should be done by:
- looking for the LLDB framework (llgdb.py does some of that)
- finding the binary inside the framework
- looking for the Python it was linked against (otool -L)
- finding the interpreter executable inside the Python.framework

But in practice, that's only different if we use a custom LLDB
framework/pythonpath when running these tests, and AFAIK nobody does
that right now, so the code would be dead anyway.

Don't pretend we can use any arbitrary python: just use the system one.

Differential Revision: https://reviews.llvm.org/D47967 — Ahmed Bougacha / ViewSVN
[X86] Add expandload and compresstore fast-isel tests for avx512f and avx512vl. Update existing tests for avx512vbmi2 to use target independent intrinsics. — ctopper / ViewSVN