Prep work for PR39467.

llvm-svn: 347067

llvm-svn: 347066

This fixes PR39669.
https://bugs.llvm.org/show_bug.cgi?id=39669

llvm-svn: 347065

Summary:
This is for supporting custom stack map formats, where the
custom printer can access the stack map data.

Patch by Cherry Zhang <cherryyz@google.com>.

Related: https://reviews.llvm.org/D53892

Reviewers: thanm, apilipenko

Reviewed By: apilipenko

Subscribers: llvm-commits

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

llvm-svn: 347061

These are baseline tests for D54532.
Patch based on the original tests by:
@nikic (Nikita Popov)

llvm-svn: 347060

This is a baseline test for D54631.
Patch by:
@nikic (Nikita Popov)

llvm-svn: 347055

Only combineX86ShufflesRecursively needs this limit.

llvm-svn: 347054

llvm-svn: 347051

Summary:
StructRet attribute is not allowed in vararg calls. The statepoint
intrinsic is vararg, but the wrapped function may be not. Allow
calls of statepoint with StructRet arg, as long as the wrapped
function is not vararg.

Reviewers: thanm, anna

Reviewed By: anna

Subscribers: anna, llvm-commits

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

llvm-svn: 347050

This is a follow-up to r346715. Use PRIx64 to formatted print of 64-bit
value in the `DWARFDebugLoclists::LocationList::dump` to escape problem
on big-endian hosts.

llvm-svn: 347049

Summary:
As discussed in previous review, and noted in the FIXME, if `X` is actually an `lshr Y, Z` (logical!),
we can fold the `Z` into 'control`, and let the `BEXTR` do this too.
We could just insert those 8 bits of shift amount into control,
but it is better to instead zero-extend them, and 'or' them in place.

We can only do this for `lshr`, not `ashr`, because we do not know that the mask cover only the bits of `Y`,
and not any of the sign-extended bits.

The obvious question is, is this actually legal to do?
I believe it is. Relevant quotes, from `Intel® 64 and IA-32 Architectures Software Developer’s Manual`, `BEXTR — Bit Field Extract`:
* `Bit 7:0 of the second source operand specifies the starting bit position of bit extraction.`
* `A START value exceeding the operand size will not extract any bits from the second source operand.`
* `Only bit positions up to (OperandSize -1) of the first source operand are extracted.`
* `All higher order bits in the destination operand (starting at bit position LENGTH) are zeroed.`
* `The destination register is cleared if no bits are extracted.`

FIXME: if we can do this, i wonder if we should prefer `BEXTR` over `BZHI` in such cases.

Reviewers: RKSimon, craig.topper, spatel, andreadb

Reviewed By: RKSimon, craig.topper, andreadb

Subscribers: llvm-commits

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

llvm-svn: 347048

Use the same variable names etc.

llvm-svn: 347045

The RISC-V ISA manual was updated on 2018-11-07 (commit 00557c3) to define a 
new compressed instruction format, RVC format CA (no actual instruction 
encodings were changed). This patch updates the RISC-V backend to define the 
new format, and to use it in the relevant instructions.

Differential Revision: https://reviews.llvm.org/D54302
Patch by Luís Marques.

llvm-svn: 347043

This commit introduces support for materialising 64-bit constants for RV64I,
making use of the RISCVMatInt::generateInstSeq helper in order to share logic
for immediate materialisation with the MC layer (where it's used for the li
pseudoinstruction).

test/CodeGen/RISCV/imm.ll is updated to test RV64, and gains new 64-bit
constant tests. It would be preferable if anyext constant returns were sign
rather than zero extended (see PR39092). This patch simply adds an explicit
signext to the returns in imm.ll.

Further optimisations for constant materialisation are possible, most notably
for mask-like values which can be generated my loading -1 and shifting right.
A future patch will standardise on the C++ codepath for immediate selection on
RV32 as well as RV64, and then add further such optimisations to
RISCVMatInt::generateInstSeq in order to benefit both RV32 and RV64 for
codegen and li expansion.

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

llvm-svn: 347042

Introduces support for '.refsym' assembler directive.

From GCC docs (for MSP430):
'.refsym' - This directive instructs assembler to add an undefined reference
to the symbol following the directive. No relocation is created for this symbol;
it will exist purely for pulling in object files from archives.

Patch by Kristina Bessonova!

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

llvm-svn: 347041

Patch by Kristina Bessonova!

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

llvm-svn: 347040

PR37970 reported non-deterministic debug output, this was caused by
iterating through a set and not a a vector.

bugzilla: https://bugs.llvm.org/show_bug.cgi?id=37970

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

llvm-svn: 347037

[LegalizeVectorTypes] Teach WidenVecRes_Convert to turn ANY_EXTEND into ANY_EXTEND_VECTOR_INREG when the input and output types need to be widened to the same width.

If we don't do it here, DAGCombine will just end up creating it from the scalar any_extend+build_vector so might as well save a step.

llvm-svn: 347034

An attempt to recommit r346584 after failure on OSX build bot.
Fixed cache key computation in ThinLTOCodeGenerator and added
test case

llvm-svn: 347033

By early promoting the multiply to use an i16 element type we can avoid op legalization emit a second multiply for the 8 upper elements of the v16i8 type we would otherwise get.

llvm-svn: 347032

[X86] Add some test cases for vector multiplies on vectors shorter than 128 bits with -x86-experimental-vector-widening-legalization.

llvm-svn: 347031

If a block had one of the _term instructions used for gluing
exec modifying instructions to the end of the block,
analyzeBranch would fail, preventing the verifier from catching
a broken successor list.

llvm-svn: 347027

When using multi-stage builds, we would like support cross-compilation.
Example is 2-stage build when the first stage is compiled for host while
the second stage is compiled for the target.

Normally, the second stage would be also used for compiling runtimes,
but that's not possible when cross-compiling, so we use the first stage
compiler instead. However, we still want to use the second stage paths.
To do so, we set the -resource-dir of the first stage compiler to point
to the resource directory of the second stage.

We also need compiler tools that support the target architecture. These
tools are not guaranteed to be present on the host, but in case of
multi-stage build, we can build these tools in the first stage.

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

llvm-svn: 347025

Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol this was, and we
re-used the PDB_SymType enumeration for this.  For native pdb support,
this is not really the right abstraction layer, because what we really
want is something that tells us *how* to find the symbol.  This means,
specifically, is in the globals stream / public stream / module stream /
TPI stream / etc, and for whichever one it is in, where is it within
that stream?

A good example of why the old namespacing scheme was insufficient is
that it is more or less impossible to create a uid for a field list
member of a class/struction/union/enum that tells you how to locate
the original record.

With this new scheme, the first byte is no longer a PDB_SymType enum
but a new enum created specifically to identify where in the PDB
this record lives.  This gives us much better flexibility in
what kinds of symbols the uids can identify.

llvm-svn: 347018

Buildbot http://lab.llvm.org:8011/builders/clang-x64-windows-msvc is failing
because it doesn't like paths in VFS, make them more Windows-friendly.

Follow up to r347009.

llvm-svn: 347016

Revert r347014 "[X86] Add some test cases for vector multiplies on vectors shorter than 128 bits with -x86-experimental-vector-widening-legalization."

Apparently I failed to update this after turnign sign extend to any extend.

llvm-svn: 347015

[X86] Add some test cases for vector multiplies on vectors shorter than 128 bits with -x86-experimental-vector-widening-legalization.

llvm-svn: 347014

llvm-svn: 347013

[X86] Use ANY_EXTEND instead of SIGN_EXTEND in the AVX2 and later path for legalizing vXi8 multiply.

We aren't going to use the upper bits of the multiply result that the extend would effect. So we don't need a specific type of extend.

This makes some reduction test cases shorter because we were previously trying to sign_extend a truncate which we can't eliminate.

llvm-svn: 347011

llvm-svn: 347010

It fixes the case when Objective-C framework is added as a subframework
through a symlink. When parent framework infers a module map and fails
to detect a symlink, it would add a subframework as a submodule. And
when we parse module map for the subframework, we would encounter an
error like

> error: umbrella for module 'WithSubframework.Foo' already covers this directory

By implementing `getRealPath` "an egregious but useful hack" in
`ModuleMap::inferFrameworkModule` works as expected.

rdar://problem/45821279

Reviewers: bruno, benlangmuir, erik.pilkington

Reviewed By: bruno

Subscribers: hiraditya, dexonsmith, JDevlieghere, cfe-commits, llvm-commits

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

llvm-svn: 347009

Add a pass to fixup various vector ISel issues.
Currently we handle converting GLOBAL_{LOAD|STORE}_*
and GLOBAL_Atomic_* instructions into their _SADDR variants.
This involves feeding the sreg into the saddr field of the new instruction.

llvm-svn: 347008

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

llvm-svn: 347007

Re-apply r346985: [ADT] Drop llvm::Optional clang-specific optimization for trivially copyable types

Remove a test case that was added with the optimization we are now
removing.

llvm-svn: 347004

Summary:
`throw` instruction is a terminator in wasm, but BBs were not splitted
after `throw` instructions, causing machine instruction verifier to
fail.

This patch
- Splits BBs after `throw` instructions in WasmEHPrepare and adding an
  unreachable instruction after `throw`, which will be deleted in
  LateEHPrepare pass
- Refactors WasmEHPrepare into two member functions
- Changes the semantics of `eraseBBsAndChildren` in LateEHPrepare pass
  to match that of WasmEHPrepare pass, which is newly added. Now
  `eraseBBsAndChildren` does not delete BBs with remaining predecessors.
- Fixes style nits, making static function names conform to clang-tidy
- Re-enables the test temporarily disabled by rL346840 && rL346845

Reviewers: dschuff

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

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

llvm-svn: 347003

llvm-svn: 347002

  - Make sure IsaInfo::hasCodeObjectV3 returns true only
    for AMDHSA
  - Update assembler metadata tests to use v2 by default

llvm-svn: 347001

Removing this code doesn't affect any lit tests so it doesn't appear to be tested anymore. I assume it was when it was added, but I guess something else changed? Code coverage report also says its unused.

I mostly didn't like that it seemed to count the sign bits as if it was a sign_extend, but then set isPositive as if it was a zero_extend. It feels like we should have picked one interpretation?

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

llvm-svn: 346995

* Add amdhsa prefix to names to allow other tools to use the metadata
  without collision.
* Make names consistent.
* Simplify structure.
* Change note record ID.
* Switch from YAML to MsgPack format.
* Document metadata assembler directive.

Patch By: t-tye (Tony Tye)
Differential Revision: https://reviews.llvm.org/D53445

llvm-svn: 346992

This reverts commit r346985.

It looks like one of the unittests also needs to be updated, reverting while I investigate.

llvm-svn: 346990