XML printer.

A test has been added that tries to comprehensively test emitting
XUnit XML output for shell tests.

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

llvm-svn: 330409

Diagnostic:
  'index must be multiple of 3 in range [-32, 28]'

Must be:
  'index must be multiple of 4 in range [-32, 28]'

llvm-svn: 330407

Summary:
This is patch [3/4] in a series to add assembler/disassembler support for
SVE's contiguous LD1 (scalar+scalar) instructions:
- Patch [1/4]: https://reviews.llvm.org/D45687
- Patch [2/4]: https://reviews.llvm.org/D45688
- Patch [3/4]: https://reviews.llvm.org/D45689
- Patch [4/4]: https://reviews.llvm.org/D45690

Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro

Reviewed By: SjoerdMeijer

Subscribers: tschuett, kristof.beyls, llvm-commits

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

llvm-svn: 330406

Hopefully, changing set to vector removes nondeterminism detected by
some bots, or the new assert will catch something.

This reverts commit r330180.

llvm-svn: 330403

llvm-svn: 330402

Reviewers: spatel, jyknight

Reviewed By: spatel

Subscribers: fedor.sergeev, llvm-commits

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

llvm-svn: 330401

llvm-svn: 330400

llvm-svn: 330399

llvm-svn: 330398

Summary:
Reading Atmel's AT697E errata document this does not seem like a valid
workaround. While the text only mentions SDIV, it says that the ICC flags
can be wrong, and those are only generated by SDIVcc. Verification on
hardware shows that simply replacing SDIV with SDIVcc does not avoid
the bug with negative operands.

This reverts r283727.

Reviewers: lero_chris, jyknight

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

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

llvm-svn: 330397

Using `clr reg`/`mov %g0, reg`/`or %g0, %g0, reg` to zero a register
looks much better than `sethi 0, reg`.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

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

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

llvm-svn: 330396

Summary:
In some cases the shift/extend needs to be explicitly parsed together
with the register, rather than as a separate operand. This is needed
for addressing modes where the instruction as a whole dictates the
scaling/extend, rather than specific bits in the instruction.
By parsing them as a single operand, we avoid the need to pass an
extra operand in all CodeGen patterns (because all operands need to
have an associated value), and we avoid the need to update TableGen to
accept operands that have no associated bits in the instruction.

An added benefit of parsing them together is that the assembler
can give a sensible diagnostic if the scaling is not correct.

This is patch [2/4] in a series to add assembler/disassembler support for
SVE's contiguous LD1 (scalar+scalar) instructions:
- Patch [1/4]: https://reviews.llvm.org/D45687
- Patch [2/4]: https://reviews.llvm.org/D45688
- Patch [3/4]: https://reviews.llvm.org/D45689
- Patch [4/4]: https://reviews.llvm.org/D45690

Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro

Reviewed By: fhahn, SjoerdMeijer

Subscribers: kristof.beyls, llvm-commits

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

llvm-svn: 330394

Summary:
This fixes a case where the argument to a sendmsg intrinsic
ends up in a VGPR, for whatever reason.

The underlying performance issue is that a multiplication that
can be an s_mul_i32 is instead needlessly generated as
v_mul_u32_u24, but this is not addressed by this patch.

Change-Id: I61fd4034314d5acdf6074632c30b65364dfa7328

Reviewers: arsenm, rampitec

Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 330393

Summary:
If a 64-bit register is used as an operand in inline assembly together
with a memory reference, the memory addressing will be wrong. The
addressing will be a single reg, instead of reg+reg or reg+imm. This
will generate a bad offset value or an exception in printMemOperand().

For example:

```
long long int val = 5;
long long int mem;
__asm__ volatile ("std %1, %0":"=m"(mem):"r"(val));
```
becomes:

```
std %i0, [%i2+589833]
```

The problem is that SelectInlineAsmMemoryOperand() is never called for
the memory references if one of the operands is a 64-bit register.
By calling SelectInlineAsmMemoryOperands() in tryInlineAsm() the Sparc
version of  SelectInlineAsmMemoryOperand() gets called for each memory
reference.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

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

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

llvm-svn: 330392

llvm-svn: 330388

Summary:
This change fixes https://crbug.com/834474, a build failure caused by
LowerTypeTests not preserving .symver symbol versioning directives for
exported functions. Emit symver information to ThinLTO summary data and
then propagate symver directives for exported functions to the merged
module.

Emitting symver information to the summaries increases the size of
intermediate build artifacts for a Chromium build by less than 0.2%.

Reviewers: pcc

Reviewed By: pcc

Subscribers: tejohnson, mehdi_amini, eraman, llvm-commits, eugenis, kcc

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

llvm-svn: 330387

Fixes some link issues.

llvm-svn: 330384

This moves the EnableLinkOnceODROutlining flag from TargetPassConfig.cpp into
MachineOutliner.cpp. It also removes OutlineFromLinkOnceODRs from the
MachineOutliner constructor. This is now handled by the moved command-line
flag.

llvm-svn: 330373

llvm-svn: 330371

This is a temporary solution until a proper WASM implementation of
MCAsmParserExtension is in place, but at least for now will unblock this
path.

Added test to make sure this path works with the WASM Assembler.

Patch By Wouter van Oortmerssen!

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

llvm-svn: 330370

Similar to rL330086, I don't know if we want to do these 
transforms here, but we might as well have the tests
here either way to show that this pass is missing 
potential functionality (intentionally or not).

llvm-svn: 330368

llvm-svn: 330366

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

llvm-svn: 330365

llvm-svn: 330364

This instruction was removed a long time so we don't need to check for it here.

llvm-svn: 330363

Summary:
The following changes addresses the following two issues.

1) The existing loop rotation pass contains both loop latch simplification and loop rotation. So one flag RotationOnly is added to be passed to the loop rotation pass.
2) The threshold value is initialized with MAX_UINT since the loop rotation utility should not have threshold limit.

Reviewers: dmgreen, efriedma

Reviewed By: efriedma

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

llvm-svn: 330362

Thanks to Alexander Ivchenko for finding the issue!

llvm-svn: 330359

Silvermont and Goldmont have the same issue on popcnt as Sandy Bridge, Haswell, Broadwell, and Skylake. Believe it is fixed in Goldmont Plus.

llvm-svn: 330358

[PM/LoopUnswitch] Detect irreducible control flow within loops and skip unswitching non-trivial edges.

Summary:
This fixes the bug pointed out in review with non-trivial unswitching.

This also provides a basis that should make it pretty easy to finish
fleshing out a routine to scan an entire function body for irreducible
control flow, but this patch remains minimal for disabling loop
unswitch.

Reviewers: sanjoy, fedor.sergeev

Subscribers: mcrosier, hiraditya, llvm-commits

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

llvm-svn: 330357

This forces these operations to be carried out via a
MaterializationResponsibility instance, ensuring responsibility is explicitly
tracked.

llvm-svn: 330356

I've copied and regenerated a resource file from btver2 to every x86 scheduler model supported by llvm-mca so we have at least some basic coverage.

For most this has been the avx1 tests, but for silvermont I've used sse42 as thats the latest it supports.

More will be added later.

llvm-svn: 330352

Luckily this was on instructions not supported on Silvermont....

llvm-svn: 330351

The XCHG16rr/XCHG32rr/XCHG64rr instructions should be 3 uops just like XCHG8rr. I believe they're just implemented as 3 move uops with a temporary register.

XADD is probably 2 moves and an add also using a temporary register.

Change the latency for both from 2 cycles to 3 cycles. Only 2 of the uops are serialized in their execution, the move into the temporary and the move out of the temporary. The move from one GPR to the other should be able to go in parallel with this if there are ALU resources available.

llvm-svn: 330349

llvm-svn: 330348

There's a lot more but I'd prefer focussing on removing unnecessary InstRWs first.

llvm-svn: 330347

This fixes https://llvm.org/PR36825.

Original patch by Valentin Churavy (D45218).

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

llvm-svn: 330345

llvm-svn: 330344

Forgot to remove it from the previous commit.

llvm-svn: 330343

When disassembling with -D, skip virtual sections by printing "..." for
each symbol.

This patch also implements `MachOObjectFile::isSectionVirtual`.

Test case comes from:

```
.zerofill __DATA,__common,_data64unsigned,472,3
```

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

llvm-svn: 330342

Summary:
Instead of manually invoking PrintStatistics, simply invoke
llvm_shutdown which will take care of destroying managed statics, and as
a side effect will destroy the StatisticInfo ManagedStatic, invoking
PrintStatistics when needed.

Reviewers: fhahn

Subscribers: inglorion, llvm-commits

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

llvm-svn: 330341