The logic that sets up lit features for sanitizers is largely copied
between here and clang, except clang's was fixed some time ago to
handle multiple sanitizers (ie, Asan + Ubsan). This just makes the
code in LLVM consistent with how it's done in clang to avoid any
gotchas by users of this.

llvm-svn: 270510

llvm-svn: 270501

This changes IRCE to optimize uses, and not branches.  This change is
NFCI since the uses we do inspect are in practice only ever going to be
the condition use in conditional branches; but this flexibility will
later allow us to analyze more complex expressions than just a direct
branch on a range check.

llvm-svn: 270500

llvm-svn: 270498

Added D20528 implementations as well as existing x86 intrinsics versions

llvm-svn: 270494

to llvm-objdump. This section is created with -fembed-bitcode option.

This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!

rdar://26202242

llvm-svn: 270491

llvm-svn: 270489

They were accidentally using the 32-bit load/store instruction for
8/16-bit operations, due to incorrect patterns

(8/16-bit cmpxchg and atomicrmw will be fixed in subsequent changes)

llvm-svn: 270486

This effectively revers commit r270389 and re-lands r270106, but it's
almost a rewrite.

The behavior change in r270106 was that we could no longer assume that
each LF_FUNC_ID record got its own type index. This patch adds a map
from DINode* to TypeIndex, so we can stop making that assumption.

This change also emits padding bytes between type records similar to the
way MSVC does. The size of the type record includes the padding bytes.

llvm-svn: 270485

When an aggregate contains an opaque type its size cannot be
determined. This triggers an "Invalid GetElementPtrInst indices for type" assert
in function checkGEPType. The fix suppresses the conversion in this case.

http://reviews.llvm.org/D20319

llvm-svn: 270479

Summary:
This patch turns on LoopUnrollAnalyzer by default. To mitigate compile
time regressions, I chose very conservative thresholds for now. Later we
can make them more aggressive, but it might require being smarter in
which loops we're optimizing. E.g. currently the biggest issue is that
with more agressive thresholds we unroll many cold loops, which
increases compile time for no performance benefit (performance of those
loops is improved, but it doesn't matter since they are cold).

Test results for compile time(using 4 samples to reduce noise):
```
MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes 5.19%
SingleSource/Benchmarks/Polybench/medley/reg_detect/reg_detect  4.19%
MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow  3.39%
MultiSource/Applications/JM/lencod/lencod 1.47%
MultiSource/Benchmarks/Fhourstones-3_1/fhourstones3_1 -6.06%
```

I didn't see any performance changes in the testsuite, but it improves
some internal tests.

Reviewers: hfinkel, chandlerc

Subscribers: llvm-commits, mzolotukhin

Differential Revision: http://reviews.llvm.org/D20482

llvm-svn: 270478

llvm-svn: 270466

Add value profile statistics with the 'show' command.

llvm-svn: 270450

The exit-on-error flag on the many_args1.ll test is needed to avoid an
unreachable in BPFTargetLowering::LowerCall. We can also avoid it by ignoring
any superfluous arguments to the call (i.e. any arguments after the first 5).

Fixes PR27766.

Differential Revision: http://reviews.llvm.org/D20471

v2 of r270419

llvm-svn: 270440

Differential Revision: http://reviews.llvm.org/D20518

llvm-svn: 270437

[X86][AVX] Added tests that access ymm registers before and after explicit vzeroupper/vzeroall calls

llvm-svn: 270434

This patch reverts r270419 because it broke a lot of buildbots,
mostly Windows. We'd like help in investigating the issues, but
for now, it should stay out.

llvm-svn: 270433

llvm-svn: 270431

llvm-svn: 270430

llvm-svn: 270425

llvm-svn: 270423

llvm-svn: 270422

The exit-on-error flag on the many_args1.ll test is needed to avoid an
unreachable in BPFTargetLowering::LowerCall. We can also avoid it by ignoring
any superfluous arguments to the call (i.e. any arguments after the first 5).

Fixes PR27766

llvm-svn: 270419

Due to an erratum in some versions of LEON, we must insert a NOP after any LD or LDF instruction to ensure the processor has time to load the value correctly before using it. This pass will implement that erratum fix.

The code will have no effect for other Sparc, but non-LEON processors.

Differential Review: http://reviews.llvm.org/D20353

llvm-svn: 270417

Reviewers: nhaustov, tstellarAMD

Subscribers: kzhuravl, arsenm

Differential Revision: http://reviews.llvm.org/D20166

llvm-svn: 270415

[AVX512] Add patterns to implement stores of extracts of least signficant subvectors using XMM or YMM stores instead of the vector extract instructions.

Similar is already done for AVX and we had lost it going to AVX512VL.

llvm-svn: 270383

llvm-svn: 270379

This isn't the complete fix, but it handles the trivial examples of duplicate vzero* ops in PR27823:
https://llvm.org/bugs/show_bug.cgi?id=27823
...and amusingly, the bogus cases already exist as regression tests, so let's take this baby step.

We'll need to do more in the general case where there's legitimate AVX usage in the function + there's
already a vzero in the code.

Differential Revision: http://reviews.llvm.org/D20477

llvm-svn: 270378

llvm-svn: 270375

We could try harder to handle non-splat vector constants too, 
but that seems much rarer to me.

Note that the div test isn't resolved because there's a check
for isIntegerTy() guarding that transform.

Differential Revision: http://reviews.llvm.org/D20497

llvm-svn: 270369

Differential Revision: http://reviews.llvm.org/D20513

llvm-svn: 270357

[AVX512] Add an AddedComplexity line to the 512-bit insert_subvector undef index 0 patterns. This gives them higher priority than the memory patterns. This matches AVX1/2.

llvm-svn: 270355

llvm-svn: 270345

[AVX512] Add a couple patterns to fix some cases where two vector mask inversions could appear in a row.

llvm-svn: 270344

Differential Revision: http://reviews.llvm.org/D20459

llvm-svn: 270336

llvm-svn: 270334

Differential Revision: http://reviews.llvm.org/D20438

llvm-svn: 270322

Differential Revision: http://reviews.llvm.org/D20324

llvm-svn: 270321

Main problem here was that SHF_COMPRESSED has the same value with
XCORE_SHF_CP_SECTION, which was included as standart (common) flag.
As far I understand xCore is a family of controllers and it that
means it's constant should be processed separately,
only if e_machine == EM_XCORE, otherwise llvm-readobj would output
different constants twice for compressed section:

Flags [
..
SHF_COMPRESSED (0x800)
..
XCORE_SHF_CP_SECTION (0x800)
..
]

what probably does not make sence if you're not working with xcore file.

Differential revision: http://reviews.llvm.org/D20273

llvm-svn: 270320

[AVX512] Add patterns for VEXTRACT v16i16->v8i16 and v32i8->v16i8. Disable AVX2 versions of vector extract when AVX512VL is enabled.

llvm-svn: 270318