llvm-svn: 233535

This leads to terribly slow compile times under MSAN. More discussion
on the commit thread of r233447.

llvm-svn: 233529

see comments http://reviews.llvm.org/D6835

llvm-svn: 233528

by Asaf Badouh (asaf.badouh@intel.com)

llvm-svn: 233525

[X86] In getHostCPUFeatures, disable xop, f16c, fma, and fma4 if OS does not support saving ymm state.

llvm-svn: 233518

[X86] Remove FeatureAES for 'corei7' CPU. 'corei7' should match 'nehalem' which doesn't have AES. Having AES and not PCLMUL makes 'corei7' halfway between Nehalem and Westmere.

llvm-svn: 233517

[X86] Use the more specific CPU names like 'nehalem', 'westmere', 'haswell', etc. Split Nehalem and Westmere CPUs.

llvm-svn: 233516

llvm-svn: 233515

llvm-svn: 233514

Summary: In dumpMemorySections a cast was too short, and in resolveRelocations a format string was too short.

Test Plan:
Enable debug build and run a program which invokes MCJIT::finalizeObject(). Saw valid input as below (highlighted addresses were previously truncated):

```
Parse relocations:
Resolving relocations Section #0	**0x7f4c1337b000**
----- Contents of section socket1 before relocations -----
**0x00007f4c1337b000**: 18 01 00 00 01 01 01 0a 00 00 00 00 04 03 02 01
0x00007f4c1337b010: 7b 1a f8 ff 00 00 00 00 18 11 00 00 05 00 00 00

```

Reviewers: lhames

Reviewed By: lhames

Subscribers: llvm-commits, ast

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

llvm-svn: 233512

llvm-svn: 233510

MCJIT.

This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.

The symbol resolution interface is modified slightly, from:

  uint64_t getSymbolAddress(const std::string &Name);

to:

  RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);

The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.


The memory management interface removes the following method:

  void notifyObjectLoaded(ExecutionEngine *EE,
                          const object::ObjectFile &) {}

as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).


The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).

The EngineBuilder class retains the existing method:

  EngineBuilder&
  setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);

and includes two new methods:

  EngineBuilder&
  setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);

  EngineBuilder&
  setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);

Clients should use EITHER:

A single call to setMCJITMemoryManager with an RTDyldMemoryManager.

OR (exclusive)

One call each to each of setMemoryManager and setSymbolResolver.

This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.

If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.

llvm-svn: 233509

llvm-svn: 233506

Add convenience function for building a typed IR Constant from trampoline
addresses.
   

llvm-svn: 233504

llvm-svn: 233502

They're harmless and it's easy to generate them from clang, leading to
a crash in LLVM. Found by afl-fuzz.

llvm-svn: 233500

llvm-svn: 233498

llvm-svn: 233495

By Asaf Badouh (asaf.badouh@intel.com)

llvm-svn: 233489

llvm-svn: 233488

Plan to use this as part of CPU 'native' support so we can stop picking a different CPU name if CPU doesn't support AVX or AVX2.

llvm-svn: 233487

All the ports have been fixed to read the feature bits from the subtarget passed
to the print methods. Also, delete the call to setAvailableFeatures in the
constructor of NVPTX's instprinter as the instprinter wasn't using the feature
bits anywhere.

llvm-svn: 233486

instead of from MCInstPrinter::AvailableFeatures.

llvm-svn: 233485

This fixes a bug I introduced in r233411.

llvm-svn: 233484

The asm syntax for the 32-bit rotate-and-mask instructions can take a 32-bit
bitmask instead of an (mb, me) pair. This syntax is not specified in the Power
ISA manual, but is accepted by GNU as, and is documented in IBM's Assembler
Language Reference. The GNU Multiple Precision Arithmetic Library (gmp)
contains assembly that uses this syntax.

To implement this, I moved the isRunOfOnes utility function from
PPCISelDAGToDAG.cpp to PPCMCTargetDesc.h.

llvm-svn: 233483

DAGCombiner::ReassociateOps was correctly testing for an constant integer scalar but failed to correctly test for constant integer vectors (it was testing for any constant vector).

llvm-svn: 233482

PPC_FP128 is really the sum of two consecutive doubles, where the first double
is always stored first in memory, regardless of the target endianness. The
memory layout of i128, however, depends on the target endianness, and so we
can't fold this without target endianness information. As a result, we must not
do this folding in lib/IR/ConstantFold.cpp (it could be done instead in
Analysis/ConstantFolding.cpp, but that's not done now).

Fixes PR23026.

llvm-svn: 233481

llvm-svn: 233475

llvm-svn: 233474

llvm-svn: 233473

instead of the one passed to the constructor.

Unfortunately, I don't have a test case for this change. In order to test my
change, I will have to run the code after line 90 in printSparcAliasInstr. I
couldn't make that happen because printAliasInstr would always handle the
printing of fcmp instructions that the code after line 90 is supposed to handle.

llvm-svn: 233471

llvm-svn: 233470

Loosen one check from r233446: as long as `DIBuilder` requires a
non-null type for every subprogram, we should allow a null type array.
Also add tests for the rest of `MDSubroutineType`, which were somehow
missing.

llvm-svn: 233468

llvm-svn: 233467

Fix testcases that don't pass the verifier after a WIP patch to check
`MDSubprogram` operands more effectively.  I found the following issues:

  - When `isDefinition: false`, the `variables:` field might point at
    `!{i32 786468}`, or at a tuple that pointed at an empty tuple with
    the comment "previously: invalid DW_TAG_base_type" (I vaguely recall
    adding those comments during an upgrade script).  In these cases, I
    just dropped the array.
  - The `variables:` field might point at something like `!{!{!8}}`,
    where `!8` was an `MDLocation`.  I removed the extra layer of
    indirection.
  - Invalid `type:` (not an `MDSubroutineType`).

llvm-svn: 233466

The original f32->f64 promotion logic was refactored into roughly the
currently shape in r37781. However, starting with r132263, the
legalizer has been split into different kinds, and the previous
"Promote" (which did the right thing) was search-and-replace'd into
"PromoteInteger". The divide gradually deepened, with type legalization
("PromoteInteger") being separated from ops legalization
("Promote", which still works for floating point ops).

Fast-forward to today: there's no in-tree target with legal f64 but
illegal f32 (rather: no tests were harmed in the making of this patch).

With such a target, i.e., if you trick the legalizer into going through
the PromoteInteger path for FP, you get the expected brokenness.
For instance, there's no PromoteIntRes_FADD (the name itself sounds
wrong), so we'll just hit some assert in the PromoteInteger path.

Don't pretend we can promote f32 to f64. Instead, always soften.

llvm-svn: 233464

subtarget.

llvm-svn: 233451

llvm-svn: 233448

Summary:
This change teaches ScalarEvolution::isLoopBackedgeGuardedByCond to look
at edges within the loop body that dominate the latch.  We don't do an
exhaustive search for all possible edges, but only a quick walk up the
dom tree.

Reviewers: atrick, hfinkel

Subscribers: llvm-commits

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

llvm-svn: 233447

Add verify checks for `MDType` subclasses and for `MDCompileUnit`.
These new checks don't yet incorporate everything from `Verify()`, but
at least they sanity check the operands.  Also downcast accessors as
possible.

A lot of these accessors can't be downcast as far as we'd like because
of arrays of typed objects (stored in a generic `MDTuple`) and
`MDString`-based type references.  Eventually I'll port over `DIRef<>`
and `DITypedArray<>` from `DebugInfo.h` to clean those up as well.

Updated bitrotted testcases separately in r233415 and r233443 to reduce
churn on the off-chance this needs to be reverted.

llvm-svn: 233446