those are in the same basic block.
The previous approach was the topological order of the basic block.

By default this rule is disabled.

Related to PR22768.

llvm-svn: 233241

llvm-svn: 233240

for PPC due to some unfortunate default setting via TargetMachine
creation. I've added a FIXME on how this can be unraveled in the
backend and a test to make sure we successfully legalize 64-bit things
if we say we're 64-bits.

llvm-svn: 233239

Otherwise, broken input modules can cause assertions.  I've updated two
of the testcases that started failing (modules that had `Require` flags
but didn't meet their own requirements), but Rafael and I decided that
test/Linker/2011-08-22-ResolveAlias.ll should just be deleted outright
-- it's a leftover of the way llvm-gcc used to implement weakref.

llvm-svn: 233229

llvm-svn: 233226

Summary:
`ComputeNumSignBits` returns incorrect results for `srem` instructions.
This change fixes the issue and adds a test case.

Reviewers: nadav, nicholas, atrick

Subscribers: llvm-commits

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

llvm-svn: 233225

This patch adds supports for the vector constant folding of TRUNCATE and FP_EXTEND instructions and tidies up the SINT_TO_FP and UINT_TO_FP instructions to match.

It also moves the vector constant folding for the FNEG and FABS instructions to use the DAG.getNode() functionality like the other unary instructions.

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

llvm-svn: 233224

As dblaikie pointed out, if I stop setting `emissionKind: 2` then the
backend won't do magical things on Linux vs. Darwin.  I had wrongly
assumed that there were stricter requirements on the input if we weren't
in line-tables-only mode, but apparently not.

With that knowledge, clean up this testcase a little more.

  - Set `emissionKind: 1`.
  - Add back checks for the weak version of @foo.
  - Check more robustly that we have the right subprograms by checking
    the `DW_AT_decl_file` and `DW_AT_decl_line` which now show up.
  - Check the line table in isolation (since it's no longer doubling as
    an indirect test for the subprogram of the weak version of @foo).

llvm-svn: 233221

llvm-svn: 233220

If liveranges induced by an IMPLICIT_DEF get completely covered by a
proper liverange the IMPLICIT_DEF instructions and its corresponding
definitions have to be removed from the live ranges. This has to happen
in the subregister live ranges as well (I didn't see this case earlier
because in most programs only some subregisters are covered and the
IMPLCIT_DEF won't get removed).

No testcase, I spent hours trying to create one for one of the public
targets, but ultimately failed because I couldn't manage to properly
control the placement of COPY and IMPLICIT_DEF instructions from an .ll
file.

llvm-svn: 233217

llvm-svn: 233216

According to at least one bot [1], function prologues aren't always
empty for these functions.  Skip that part of the follow-up check.

llvm-svn: 233214

llvm-svn: 233213

We don't have any logic to emit those tables yet, so the sdag lowering
of this intrinsic is just a stub. We can see the intrinsic in the
prepared IR, though.

llvm-svn: 233209

Rewrite the checks from r233164 that I temporarily disabled in r233165.

It turns out that the line-tables only debug info we emit from `llc` is
(intentionally) different on Linux than on Darwin.  r218129 started
skipping emission of subprograms with no inlined subroutines, and
r218702 was a spiritual revert of that behaviour for Darwin.

I think we can still test this in a platform-neutral way.

  - Stop checking for the possibly missing `DW_TAG_subprogram` defining
    the debug info for the real version of `@foo`.
  - Start checking the line tables, ensuring that the right debug info
    was used to generate them (grabbing `DW_AT_low_pc` from the compile
    unit).
  - I changed up the line numbers used in the "weak" version so it's
    easier to follow.

This should hopefully finish off PR22792.

llvm-svn: 233207

llvm-svn: 233206

This patch adds Hardware Transaction Memory (HTM) support supported by ISA 2.07
(POWER8). The intrinsic support is based on GCC one [1], but currently only the
'PowerPC HTM Low Level Built-in Function' are implemented.

The HTM instructions follows the RC ones and the transaction initiation result
is set on RC0 (with exception of tcheck). Currently approach is to create a
register copy from CR0 to GPR and comapring. Although this is suboptimal, since
the branch could be taken directly by comparing the CR0 value, it generates code
correctly on both test and branch and just return value. A possible future
optimization could be elimitate the MFCR instruction to branch directly.

The HTM usage requires a recently newer kernel with PPC HTM enabled. Tested on
powerpc64 and powerpc64le.

This is send along a clang patch to enabled the builtins and option switch.

[1] https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Hardware-Transactional-Memory-Built-in-Functions.html

Phabricator Review: http://reviews.llvm.org/D8247

llvm-svn: 233204

llvm-svn: 233203

llvm-svn: 233201

Some languages, such as Go, have pre-defined structure types (e.g. "string"
is essentially a pointer/length pair) or pre-defined "typedef" types
(e.g. "error" is essentially a typedef for a specific interface type).
Such types do not have associated source location, so a Go frontend would
be correct not to associate a file name with such types.

This change relaxes the DIType verifier to permit unlocated types with
these tags.

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

llvm-svn: 233200

This patch allows AVX blend instructions to handle insertion into the low
element of a 256-bit vector for the appropriate data types.

For f32, instead of:

   vblendps	$1, %xmm1, %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[1,2,3]
   vblendps	$15, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0,1,2,3],ymm0[4,5,6,7]

we get:

   vblendps	$1, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0],ymm0[1,2,3,4,5,6,7]

For f64, instead of:

   vmovsd	%xmm1, %xmm0, %xmm1     ## xmm1 = xmm1[0],xmm0[1]
   vblendpd	$3, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0,1],ymm0[2,3]

we get:

   vblendpd	$1, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0],ymm0[1,2,3]

For the hardware-neglected integer data types, I left a TODO comment in the
code and added regression tests for a follow-on patch.

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

llvm-svn: 233199

1. There were no CHECK-LABELs, so we could match instructions from the wrong function.
2. The use of zero operands meant multiple xor instructions could match some CHECKs.
3. The test was over-specified to need a Sandybridge CPU and Darwin triple.

llvm-svn: 233198

This code is only compiled when LLVM_USE_INTEL_JITEVENTS, but at least we have
one buildbot where that's the case :)

llvm-svn: 233197

To complement getSplat. This is more general than the binary
decomposition method as it also handles non-pow2 splat sizes.

llvm-svn: 233195

No functional change intended.

llvm-svn: 233192

Hopefully makes it a bit easier to understand what's going on.
No functional change intended.

llvm-svn: 233191

The other version doesn't properly work with our internal test runner,
which sets pipefail.

llvm-svn: 233188

The previous logic was to first try without relocations at all
and failing that stop on the first defined symbol.

That was inefficient and incorrect in the case part of the
expression could be simplified and another part could not
(see included test).

We now stop the evaluation when we get to a variable whose value
can change (i.e. is weak).

llvm-svn: 233187

llvm-svn: 233184

Added test Float2Int/float2int-optnone.ll to verify that pass Float2Int
is not run on optnone functions.

llvm-svn: 233183

This ensures that we're building and testing the CompileOnDemand layer, at least
in a basic way.

Currently x86-64 only, and with limited to no library calls enabled (depending
on host platform). Patches welcome. ;)

To enable access to the lazy JIT, this patch replaces the '-use-orcmcjit' lli
option with a new option:
'-jit-kind={ mcjit | orc-mcjit | orc-lazy }'.

All regression tests are updated to use the new option, and one trivial test of
the new lazy JIT is added.

llvm-svn: 233182

Also, removed unused check lines from test atomic6432.ll.

llvm-svn: 233181

Now with a fix for PR23008 and extra regression test.

llvm-svn: 233175

In r233009 we gained specific check-llvm-* build targets for invoking
specific parts of the test suite, but they were copying the
dependencies for check-all, rather than just listing the dependencies
for check-llvm.

This moves the creation of these targets next to the check-llvm
target, and uses that target's configuration rather than the check-all
config.

llvm-svn: 233174

llvm-svn: 233171

[X86] Remove GetCpuIDAndInfo, GetCpuIDAndInfoEx and DetectFamilyModel functions from X86 MC layer. They haven't been used since CPU autodetection was removed from X86Subtarget.cpp.

llvm-svn: 233170

llvm-svn: 233168

target-independent callback management.

This is a prerequisite for adding orc-based lazy-jitting to lli.

llvm-svn: 233166

At least one Linux bot [1] doesn't like my dwarfdump checks, so I've
disable those until I can investigate what's going on there.  I'll
continue to track this in PR22792.

[1]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/22863

llvm-svn: 233165

Instead of dropping subprograms that have been overridden, just set
their function pointers to `nullptr`.  This is a minor adjustment to the
stop-gap fix for PR21910 committed in r224487, and fixes the crasher
from PR22792.

The problem that r224487 put a band-aid on: how do we find the canonical
subprogram for a `Function`?  Since the backend currently relies on
`DebugInfoFinder` (which does a naive in-order traversal of compile
units and picks the first subprogram) for this, r224487 tried dropping
non-canonical subprograms.

Dropping subprograms fails because the backend *also* builds up a map
from subprogram to compile unit (`DwarfDebug::SPMap`) based on the
subprogram lists.  A missing subprogram causes segfaults later when an
inlined reference (such as in this testcase) is created.

Instead, just drop the `Function` pointer to `nullptr`, which nicely
mirrors what happens when an already-inlined `Function` is optimized
out.  We can't really be sure that it's the same definition anyway, as
the testcase demonstrates.

This still isn't completely satisfactory.  Two flaws at least that I can
think of:

  - I still haven't found a straightforward way to make this symmetric
    in the IR.  (Interestingly, the DWARF output is already symmetric,
    and I've tested for that to be sure we don't regress.)
  - Using `DebugInfoFinder` to find the canonical subprogram for a
    function is kind of crazy.  We should just attach metadata to the
    function, like this:

        define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) {

llvm-svn: 233164