It triggered a bot failture somehow today:
http://lab.llvm.org:8011/builders/lld-perf-testsuite/builds/7993

llvm-svn: 344344

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

llvm-svn: 344343

MipsGotSection::FileGot::isOverflow()
was a dead declararion.

llvm-svn: 344342

llvm-svn: 344341

[clang-tidy] White List Option for performance-unnecessary-value-param, performance-unnecessary-copy-initialization and performance-for-range-copy

New option added to these three checks to be able to silence false positives on
types that are intentionally passed by value or copied. Such types are e.g.
intrusive reference counting pointer types like llvm::IntrusiveRefCntPtr. The
new option is named WhiteListTypes and can contain a semicolon-separated list of
names of these types. Regular expressions are allowed. Default is empty.

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

llvm-svn: 344340

llvm-svn: 344339

The documentation stated "Access to explicit operands of the
instruction." This is misleading, as it also lists implicit operands.

Patch by Philip Ginsbach.

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

llvm-svn: 344338

Reviewers: ilya-biryukov

Subscribers: arphaman, cfe-commits

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

llvm-svn: 344337

Fixes PR32160 by reducing the size of PSHUFB if we only use one of the lanes.

This approach can probably be generalized to handle any target shuffle (and any subvector index) but we have no test coverage at the moment.

llvm-svn: 344336

llvm-svn: 344335

This patch adds the ability to identify instructions that are "move elimination
candidates". It also allows scheduling models to describe processor register
files that allow move elimination.

A move elimination candidate is an instruction that can be eliminated at
register renaming stage.
Each subtarget can specify which instructions are move elimination candidates
with the help of tablegen class "IsOptimizableRegisterMove" (see
llvm/Target/TargetInstrPredicate.td).

For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated.
The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this:

```
def : IsOptimizableRegisterMove<[
  InstructionEquivalenceClass<[
    // GPR variants.
    MOV32rr, MOV64rr,

    // MMX variants.
    MMX_MOVQ64rr,

    // SSE variants.
    MOVAPSrr, MOVUPSrr,
    MOVAPDrr, MOVUPDrr,
    MOVDQArr, MOVDQUrr,

    // AVX variants.
    VMOVAPSrr, VMOVUPSrr,
    VMOVAPDrr, VMOVUPDrr,
    VMOVDQArr, VMOVDQUrr
  ], CheckNot<CheckSameRegOperand<0, 1>> >
]>;
```

Definitions of IsOptimizableRegisterMove from processor models of a same
Target are processed by the SubtargetEmitter to auto-generate a target-specific
override for each of the following predicate methods:

```
bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI)
const;
bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned
CPUID) const;
```

By default, those methods return false (i.e. conservatively assume that there
are no move elimination candidates).

Tablegen class RegisterFile has been extended with the following information:
 - The set of register classes that allow move elimination.
 - Maxium number of moves that can be eliminated every cycle.
 - Whether move elimination is restricted to moves from registers that are
   known to be zero.

This patch is structured in three part:

A first part (which is mostly boilerplate) adds the new
'isOptimizableRegisterMove' target hooks, and extends existing register file
descriptors in MC by introducing new fields to describe properties related to
move elimination.

A second part, uses the new tablegen constructs to describe move elimination in
the BtVer2 scheduling model.

A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove'
hook to mark instructions that are candidates for move elimination. It also
teaches class RegisterFile how to describe constraints on move elimination at
PRF granularity.

llvm-mca tests for btver2 show differences before/after this patch.

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

llvm-svn: 344334

llvm-svn: 344333

[X86][AVX] Add examples of shuffles that can be reduced to a cross-lane shuffle followed by a in-lane permute

Suitable for lowering by D53148

llvm-svn: 344332

Scalar non-temporal loads were asserting instead of just being ignored.

Reduced from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10895

llvm-svn: 344331

Reviewers: kadircet

Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits

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

llvm-svn: 344330

This is a follow-up patch to r342541. After further investigations, only
48bits VMA size can be supported. As this is enforced in function
InitializePlatformEarly from lib/rt1/tsan_platform_linux.cc, the access
to the global variable vmaSize variable + switch can be removed. This
also addresses a comment from https://reviews.llvm.org/D52167.

vmaSize of 39 or 42bits are not compatible with a Go program memory
layout as the Go heap will not fit in the shadow memory area.

Patch by: Fangming Fang <Fangming.Fang@arm.com>

llvm-svn: 344329

LLDB does not support this DWARF5 form atm.
At least gcc emits it in some cases when doing optimization
for abbreviations.

As far I can tell, clang does not support it yet, though
the rest LLVM code already knows about it.

The patch adds the support.

Differential revision: https://reviews.llvm.org/D52689

llvm-svn: 344328

Later calls to getValueState might insert entries into the ValueState map and
cause reallocation, invalidating a reference.

llvm-svn: 344327

Failure was discovered upon running
projects/compiler-rt/test/builtins/Unit/divtc3_test.c
in a stage2 compiler build.

When compiling projects/compiler-rt/lib/builtins/divtc3.c,
a call to fmaxl within the divtc3 implementation had its
return values read from registers $2 and $3 instead of $f0 and $f2.
Include fmaxl in the list of long double emulation routines
to have its return value correctly interpreted as f128.

Almost exact issue here: https://reviews.llvm.org/D17760

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

llvm-svn: 344326

Differential revision: https://reviews.llvm.org/D53139

llvm-svn: 344325

Fix bug where `config.asan_dynamic` in generated ASan `lit.site.cfg` files was set to `False` for macOS.

`config.asan_dynamic` should actually be `True` because dylibs are the
only supported form of the ASan runtime on Apple platforms.

Reviewers: kubamracek, george.karpenkov, samsonov

Subscribers: srhines, mgorny, #sanitizers, llvm-commits

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

llvm-svn: 344324

llvm-svn: 344323

Pointed out by Artem in post-commit review for https://reviews.llvm.org/D53058

llvm-svn: 344322

Summary:
This change adds support for the GNU --target flag, which sets both --input-target and --output-target.

GNU objcopy doesn't do any checking for whether both --target and --{input,output}-target are used, and so it allows both, e.g. "--target A --output-target B" is equivalent to "--input-target A --output-target B" since the later command line flag would override earlier ones. This may be error prone, so I chose to implement it as an error if both are used. I'm not sure if anyone is actually using both.

Reviewers: jakehehrlich, jhenderson, alexshap

Reviewed By: jakehehrlich, alexshap

Subscribers: llvm-commits

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

llvm-svn: 344321

  
I want to add another pattern here that includes scalar_to_vector,
so this makes that patch smaller. I was hoping to remove the
hasOneUse() check because it shouldn't be necessary for common
codegen, but an AMDGPU test has a comment suggesting that the
extra check makes things better on one of those targets.

llvm-svn: 344320

llvm-cxxmap documentation.

Add a hint as to how to perform off-line profile data remapping.

llvm-svn: 344319

It originally triggered a stepping problem in the debugger, which could
be fixed by adjusting CodeGen/LexicalScopes.cpp however it seems we prefer
the previous behavior anyway.

See the discussion for details: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181008/593833.html

This reverts commit r343880.
This reverts commit r343874.

llvm-svn: 344318

This reverts commit r344310.

The test case was failing on some bots.

llvm-svn: 344317

This directory uses LLVM style.

llvm-svn: 344316

DIV/REM by constants should always be expanded into mul/shift/etc.
patterns. Unfortunately the ConstantHoisting pass runs too early at a
point where the pattern isn't expanded yet. However after
ConstantHoisting hoisted some immediate the result may not expand
anymore. Also the hoisting typically doesn't make sense because it
operates on immediates that will change completely during the expansion.

Report DIV/REM as TCC_Free so ConstantHoisting will not touch them.

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

llvm-svn: 344315

Summary:
We have two copies of createPrivateGlobalForString (in asan and in esan).
This change merges them into one. NFC

Reviewers: vitalybuka

Reviewed By: vitalybuka

Subscribers: llvm-commits

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

llvm-svn: 344314

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

llvm-svn: 344313

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

llvm-svn: 344312

For now, tresting the cast as a no-op, and disregarding the case where
the output becomes null due to the type mismatch.

rdar://45174557

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

llvm-svn: 344311

Reviewers: arsenm

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 344310

Summary:
Instruction with 0 in fence field being disassembled as fence , iorw.
Printing "unknown" to match GAS behavior.

This bug was uncovered by a LLVM MC Disassembler Protocol Buffer Fuzzer
for the RISC-V assembly language.

Reviewers: asb

Subscribers: rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, asb

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

llvm-svn: 344309

llvm-svn: 344308

In this diff we move out CopyConfig from llvm-oobjcopy.cpp into a separate header CopyConfig.h
to enable us (in the future) reuse this class in the other implementations of objcopy (for coff, mach-o).
Additionally this enables us to unload the complexity from llvm-objcopy.cpp a little bit.

Test plan: make check-all

Differential revision: https://reviews.llvm.org/D53006

llvm-svn: 344307

llvm-svn: 344306

addAbsolute() could be implemented as a non-member function.

llvm-svn: 344305