llvm-svn: 233763

llvm-svn: 233761

replaceWithUniquedUnresolved
replaceWithUniquedUnresolvedChangedOperand
 =>
replaceWithUniquedResolvingOperand
replaceWithUniquedChangingOperand

I find the new names less confusing; they're also more accurate.  Sorry
for the churn.

llvm-svn: 233759

r233664 fixed the `Verifier` so that it doesn't crash on bad type refs.
This deserves a test!

llvm-svn: 233756

Even at -O0, we fall back to SDAG when we hit intrinsics, and if the intrinsic
is a memset/memcpy/etc. we might normally use vector types. At -O0, this is
probably not a good idea (because, if there is a bug in the lowering code,
there would be no good way to turn it off). At -O0, only use scalar preferred
types.

Related to PR22754.

llvm-svn: 233755

extended loads.
Implement the related target lowering hook so that the optimization has a better
estimation of the cost of an extension.

rdar://problem/19267165

llvm-svn: 233753

llvm-svn: 233752

Uniqued nodes have more complete registration with
`ReplaceableMetadataImpl` so that they can update themselves when
operands change.  Fix a bug where `MDNode::replaceWithUniqued()` wasn't
enabling these callbacks.

The two most obvious ways missing callbacks causes problems is that
auto-resolution fails and re-uniquing (on changed operands) just doesn't
happen.  I've added tests for both -- in both cases, I confirmed that
the final check was failing before the fix.

rdar://problem/20365935

llvm-svn: 233751

Commit r233747 fixed the issue that had been blocking this.

llvm-svn: 233750

The existing code in getMemsetValue only handled integer-preferred types when
the fill value was not a constant. Make this more robust in two ways:

  1. If the preferred type is a floating-point value, do the mul-splat trick on
     the corresponding integer type and then bitcast.
  2. If the preferred type is a vector, do the mul-splat trick on one vector
     element, and then build a vector out of them.

Fixes PR22754 (although, we should also turn off use of vector types at -O0).

llvm-svn: 233749

This patch fixes MCJIT::addGlobalMapping by changing the implementation of the
ExecutionEngineState class. The new implementation maintains a bidirectional
mapping between symbol names (std::strings) and addresses (uint64_ts), rather
than a mapping between Value*s and void*s.

This has fix has been made for backwards compatibility, however the strongly
preferred way to resolve unknown symbols is by writing a custom
RuntimeDyld::SymbolResolver (formerly RTDyldMemoryManager) and overriding the
findSymbol method. The addGlobalMapping method is a hangover from the legacy JIT
(which has was removed in 3.6), and may be deprecated in a future release as
part of a clean-up of the ExecutionEngine interface.

Patch by Murat Bolat. Thanks Murat!

llvm-svn: 233747

llvm-svn: 233745

llvm-svn: 233744

Specify an allocation order with a register class. This is used by register
allocators with a greedy heuristic. This is usefull as it is sometimes
beneficial to color more constrained classes first.

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

llvm-svn: 233743

When allocating live intervals in linear order and all of them are local
to a single basic block you get an optimal coloring. This is also true
if you reverse the order, but it is not true if you sort live ranges
beginnings in reverse order, change to sort live range endings in
reverse order. Take the following live ranges for example:

   |---| |--------|
|----------| |-------|

They get colored suboptimally with 3 registers if you sort the live range
starting points in reverse order (but optimally with live range begins in order,
or live range ends in reverse order).

Apparently the previous strategy was intentional because of allocation
time considerations. I am having a hard time replicating these effects,
while I see substantial improvements in allocation quality with this
change.

No testcase as none of the (in tree) targets use reverse order mode.

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

llvm-svn: 233742

No functional changes.

llvm-svn: 233740

Change lowerCTPOP to:
- Gracefully handle a known-zero input value
- Simplify computation of significant bit size

Thanks to Jay Foad for the review!

llvm-svn: 233736

This is a follow-on to r233704 and another partial fix for PR22685:
https://llvm.org/bugs/show_bug.cgi?id=22685

llvm-svn: 233724

These regression tests are supposed to test small code model support, but have
been XFAIL'd because we don't have an in-tree memory manager that can guarantee
a small-code-model compatible memory layout. Unfortunately, they can
occasionally pass if they get lucky with memory allocation, causing unexpected
passes on the bots. That's not very helpful.

I'm going to remove these until we have the infrastructure (small-code-model
compatible memory manager) to run them properly.

llvm-svn: 233722

llvm-svn: 233709

It didn't work with "install".

llvm-svn: 233708

I suggested this change in D7898 (http://llvm.org/viewvc/llvm-project?view=revision&revision=231354)

It improves the v4i64 case although not optimally. This AVX codegen:

  vmovq {{.*#+}} xmm0 = mem[0],zero
  vxorpd %ymm1, %ymm1, %ymm1
  vblendpd {{.*#+}} ymm0 = ymm0[0],ymm1[1,2,3]

Becomes:

  vmovsd {{.*#+}} xmm0 = mem[0],zero

Unfortunately, this doesn't completely solve PR22685. There are still at least 2 problems under here:

    We're not handling v32i8 / v16i16.
    We're not getting the FP / int domains right for instruction selection.

But since this patch alone appears to do no harm, reduces code duplication, and helps v4i64, 
I'm submitting this patch ahead of fixing the above.

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

llvm-svn: 233704

llvm-svn: 233701

Should fix build failures with cmake builds

llvm-svn: 233700

llvm-svn: 233699

This time with all files included.

llvm-svn: 233696

llvm-svn: 233695

llvm-svn: 233694

Reviewers: t.p.northover, jmolloy

Subscribers: llvm-commits

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

llvm-svn: 233693

So far, we do not yet support any instruction specific to zEC12.
Most of the facilities added with zEC12 are indeed not very useful
to compiler code generation, but there is one exception: the
miscellaneous-extensions facility provides the RISBGN instruction,
which is a variant of RISBG that does not set the condition code.

Add support for this facility, MC support for RISBGN, and CodeGen
support for prefering RISBGN over RISBG on zEC12, unless we can
actually make use of the condition code set by RISBG.

llvm-svn: 233690

We already exploit a number of instructions specific to z196,
but not yet POPCNT.  Add support for the population-count
facility, MC support for the POPCNT instruction, CodeGen
support for using POPCNT, and implement the getPopcntSupport
TargetTransformInfo hook.

llvm-svn: 233689

This hooks up the TargetTransformInfo machinery for SystemZ,
and provides an implementation of getIntImmCost.

In addition, the patch adds the isLegalICmpImmediate and
isLegalAddImmediate TargetLowering overrides, and updates
a couple of test cases where we now generate slightly
better code.

llvm-svn: 233688

Fixes pr22995.

llvm-svn: 233686

As was done for X86 in r206094.

llvm-svn: 233684

 it more liberally.

SplitVecOp_TRUNCATE has logic for recursively splitting oversize vectors
that need more than one round of splitting to become legal. There are many
other ISD nodes that could benefit from this logic, so factor it out and
use it for FP_TO_UINT,FP_TO_SINT,SINT_TO_FP,UINT_TO_FP and FTRUNC.

llvm-svn: 233681

[X86] Stop changing result of getHostCPUName based on whether the processor supports AVX. getHostCPUFeatures should be used instead to determine whether to support AVX.

llvm-svn: 233674

This is necessary for x86 where not all Sandybridge, Ivybrige, Haswell, and Broadwell CPUs support AVX. Currently we modify the CPU name back to Nehalem for this case, but that turns off additional features for these CPUs.

llvm-svn: 233673

[X86] Be more robust against unknown Intel family 6 models. Use feature flags to guess what it might be.

llvm-svn: 233671

We used to miss non-Q YMM integer vectors, and, non-Q/D XMM integer
vectors.
While there, change the v4i32 patterns to prefer MOVNTDQ.

llvm-svn: 233668

Unify the error messages for the various tools when `verifyModule()`
fails on an input module.  The "brave new way" is:

    lltool: path/to/input.ll: error: input module is broken!

llvm-svn: 233667