Calm down build bots

r221975 seemed to trigger an ambiguous conversion that only irritated
clang, not gcc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221977 91177308-0d34-0410-b5e6-96231b3b80d8

obj2yaml, yaml2obj: Add support for COFF executables

In support of serializing executables, obj2yaml now records the virtual address
and size of sections.  It also serializes whatever we strictly need from
the PE header, it expects that it can reconstitute everything else via
inference.

yaml2obj can reconstitute a fully linked executable.

In order to get executables correctly serialized/deserialized, other
bugs were fixed as a circumstance.  We now properly respect file and
section alignments.  We also avoid writing out string tables unless they
are strictly necessary.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221975 91177308-0d34-0410-b5e6-96231b3b80d8

Use size_type for operator[].

This matches std::vector and is more efficient as it avoids
truncations.

With this the text segment of opt goes from 19705442 bytes
to 19703930 bytes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221973 91177308-0d34-0410-b5e6-96231b3b80d8

SearchForAddressOfSymbol(): Disable 3 symbols, copysignf, fminf, and fmaxf, on msc17. *These were added in VS 2013*

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221971 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Make constant array static

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221965 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-cov: Sink some reporting logic into CoverageMapping

This teaches CoverageMapping::getCoveredFunctions to filter to a
particular file and uses that to replace most of the logic found in
llvm-cov report.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221962 91177308-0d34-0410-b5e6-96231b3b80d8

X86: use getConstant rather than getTargetConstant behind BUILD_VECTOR.

getTargetConstant should only be used when you can guarantee the instruction
selected will be able to cope with the raw value. BUILD_VECTOR is rather too
generic for this so we should use getConstant instead. In that case, an
instruction can still consume the constant, but if it doesn't it'll be
materialised through its own round of ISel.

Should fix PR21352.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221961 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Rewrite uniquing and creation of MDString

Stop using `Value::getName()` to get the string behind an `MDString`.
Switch to `StringMapEntry<MDString>` so that we can find the string by
its coallocation.

This is part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221960 91177308-0d34-0410-b5e6-96231b3b80d8

StringMap: Test and finish off supporting perfectly forwarded values in StringMap operations.

Followup to r221946.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221958 91177308-0d34-0410-b5e6-96231b3b80d8

Fix 80 cols caught by the linter...

We have a linter running in our build now?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221957 91177308-0d34-0410-b5e6-96231b3b80d8

Fix build of Mips code with MSVC by using our macro instead of __attribute__((unused)) directly

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221956 91177308-0d34-0410-b5e6-96231b3b80d8

Allow the use of functions as typeinfo in landingpad clauses

This is one step towards supporting SEH filter functions in LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221954 91177308-0d34-0410-b5e6-96231b3b80d8

CodeGen: assert an instruction is being inserted with the correct iterator.

When "MBB->Insert(It, ...)" is called, we want It to be pointing inside the
correct basic block. No actual failures at the moment, but it's caused problems
before.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221953 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Make MDString::getName() private

Hide the fact that `MDString`'s string is stored in `Value::Name` --
that's going to change soon.  Update the only in-tree client that was
using it instead of `Value::getString()`.

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221951 91177308-0d34-0410-b5e6-96231b3b80d8

Fix the VS 2012 build

VS 2012 doesn't have fminf or fmaxf.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221949 91177308-0d34-0410-b5e6-96231b3b80d8

First stage of call lowering for Mips fast-isel

Summary:
This has most of what is needed for mips fast-isel call lowering for O32.
What is missing I will add on the next patch because this patch is already too large.
It should not be doing anything wrong but it will punt on some cases that it is basically
capable of doing.

The mechanism is there for parameters to be passed on the stack but I have not enabled it because it serves as a way for now to prevent some of the strange cases of O32 register passing that I have not fully checked yet and have some issues.

The Mips O32 abi rules are very complicated as far how data is passed in floating and integer registers.

However there is a way to think about this all very simply and this implementation reflects that.

Basically, the ABI rules are written as if everything is passed on the stack and aligned as such.
Once that is conceptually done, it is nearly trivial to reassign those locations to registers and
then all the complexity disappears.

So I have told tablegen that all the data is passed on the stack and during the lowering I fix
this by assigning to registers as per the ABI doc.

This has been my approach and you can line up what I did with the ABI document and see 1 to 1 what
is going on.

Test Plan: callabi.ll

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: jholewinski, echristo, ahatanak, llvm-commits, rfuhler

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221948 91177308-0d34-0410-b5e6-96231b3b80d8

Fix symbol resolution of floating point libc builtins in MCJIT

Fix for LLI failure on Windows\X86: http://llvm.org/PR5053

LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh

The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).

For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.

Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols.  However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.

Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations.  The address of these
helper functions are used to patch up the CALL instruction at load time.

Reviewers: lhames, rnk

Reviewed By: rnk

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

Patch by Swaroop Sridhar!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221947 91177308-0d34-0410-b5e6-96231b3b80d8

ADT: Use perfect forwarding in StringMapEntry::Create()

Now you can pass references into constructors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221946 91177308-0d34-0410-b5e6-96231b3b80d8

Relax the gcov version.ll test to check '.' instead of '\*'

The escaping of the '\*' doesn't work with my combination of testing
tools.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221944 91177308-0d34-0410-b5e6-96231b3b80d8

Silence MSVC warning on missing return after fully covered switch

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221943 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Fix fmin_legacy / fmax_legacy matching for SI

select_cc is expanded on SI, so this was never matched.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221941 91177308-0d34-0410-b5e6-96231b3b80d8

Use nullptr instead of NULL for variadic sentinels

Windows defines NULL to 0, which when used as an argument to a variadic
function, is not a null pointer constant. As a result, Clang's
-Wsentinel fires on this code. Using '0' would be wrong on most 64-bit
platforms, but both MSVC and Clang make it work on Windows. Sidestep the
issue with nullptr.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221940 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "[GVN] Perform Scalar PRE on gep indices that feed loads before doing Load PRE."

This reverts commit r221924.  It appears the commit was a bit premature and is causing
bot failures that need further investigation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221939 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Add some tests for specific patterns of lane-flips combined with
in-lane shuffles that aren't always handled well by the current vector
shuffle lowering.

No functionality change yet, that will follow in a subsequent commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221938 91177308-0d34-0410-b5e6-96231b3b80d8

Move calls to push_back out of readAbbreviated(Literal|Field).

These functions always return a single value and not all callers want to
push them into a SmallVector.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221934 91177308-0d34-0410-b5e6-96231b3b80d8

Avoid usage of char16_t as MSVC "14" doesn't appear to support it

Fixes the MSVC "14" build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221932 91177308-0d34-0410-b5e6-96231b3b80d8

Fix nested namespace with decltype to hopefully work with MSVC

Build failed here:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/14629/steps/build_Lld/logs/stdio

So I'm taking a shot in the dark that MSVC (whatever version that is)
can't cope with nested name specifiers with a decltype prefix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221931 91177308-0d34-0410-b5e6-96231b3b80d8

Make a few helper functions static. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221930 91177308-0d34-0410-b5e6-96231b3b80d8

Use unique_ptr to handle ownership of TreePatterns in CodeGenDAGPatterns::PatternFragments

We might be able to use unique_ptr to handle ownership of the
TreePatternNodes too - looking into that next.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221928 91177308-0d34-0410-b5e6-96231b3b80d8

We can get the TLOF from the TargetMachine - so constructor no longer requires TargetLoweringObjectFile to be passed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221926 91177308-0d34-0410-b5e6-96231b3b80d8

[GVN] Perform Scalar PRE on gep indices that feed loads before doing Load PRE.

Phabricator Revision: http://reviews.llvm.org/D6103
Patch by "Balaram Makam" <bmakam@codeaurora.org>!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221924 91177308-0d34-0410-b5e6-96231b3b80d8

[FastISel][AArch64] Don't bail during simple GEP instruction selection.

The generic FastISel code would bail, because it can't emit a sign-extend for
AArch64. This copies the code over and uses AArch64 specific emit functions.

This is not ideal and 'computeAddress' should handles this, so it can fold the
address computation into the memory operation.

I plan to clean up 'computeAddress' anyways, so I will add that in a future
commit.

Related to rdar://problem/18962471.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221923 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Use s_movk_i32

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221922 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Fix definition for s_cselect_b32

These were directly using the old base instruction
class, and specifying the wrong register classes
for operands. The operands can be the other special
inputs besides SGPRs. The op name was also being
directly used for the asm string, so this was printed
without any operands.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221921 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Fix assert on empty function

If a function is just an unreachable, this would hit a
"this is not a MachO target" assertion because of setting
HasSubsectionViaSymbols.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221920 91177308-0d34-0410-b5e6-96231b3b80d8

Un-break the big-endian buildbots

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221919 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Error on initializer for LDS.

Also give a proper error for other address spaces.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221917 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Get rid of FCLAMP_SI pseudo

It's not necessary. Also use complex patterns to allow
src modifier usage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221916 91177308-0d34-0410-b5e6-96231b3b80d8

Object, Mach-O: Refactor and clean code up

Don't assert if we can return an error code, reuse existing
functionality like is64Bit().

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221915 91177308-0d34-0410-b5e6-96231b3b80d8

Use -Wcast-qual in cmake builds, not only autoconfo ones.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221913 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Allow commuting with src2_modifiers

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221911 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Allow commuting some 3 op instructions

e.g. v_mad_f32 a, b, c -> v_mad_f32 b, a, c

This simplifies matching v_madmk_f32.

This looks somewhat surprising, but it appears to be
OK to do this. We can commute src0 and src1 in all
of these instructions, and that's all that appears
to matter.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221910 91177308-0d34-0410-b5e6-96231b3b80d8

Return word_t from read.

This removes the need for a special Read64.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221909 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: allow constpool entry to be moved to the user's block in all cases.

Normally entries can only move to a lower address, but when that wasn't viable,
the user's block was considered anyway. Unfortunately, it went via
createNewWater which wasn't designed to handle the case where there's already
an island after the block.

Unfortunately, the test we have is slow and fragile, and I couldn't reduce it
to anything sane even with the @llvm.arm.space intrinsic. The test change here
is recreating the previous one after the change.

rdar://problem/18545506

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221905 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: avoid duplicating branches during constant islands.

We were using a naive heuristic to determine whether a basic block already had
an unconditional branch at the end. This mostly corresponded to reality
(assuming branches got optimised) because there's not much point in a branch to
the next block, but could go wrong.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221904 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: add @llvm.arm.space intrinsic for testing ConstantIslands.

Creating tests for the ConstantIslands pass is very difficult, since it depends
on precise layout details. Having the ability to precisely inject a number of
bytes into the stream helps greatly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221903 91177308-0d34-0410-b5e6-96231b3b80d8

Fix the other build system.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221901 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a regression on the disassembling C API.

The fix is easy. Unfortunately, we had 0 tests, so adding one was somewhat
complicated.

Thanks to Kevin Enderby for the report.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221899 91177308-0d34-0410-b5e6-96231b3b80d8

[Hexagon]
NFC Renaming reserved identifier.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221898 91177308-0d34-0410-b5e6-96231b3b80d8

[Reassociate] Update comment. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221894 91177308-0d34-0410-b5e6-96231b3b80d8

Simplify code a bit. NFC.

Thanks to Sean Silva for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221892 91177308-0d34-0410-b5e6-96231b3b80d8

Small optimization: once the size is know, we don't have to call fillCurWord.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221891 91177308-0d34-0410-b5e6-96231b3b80d8

Fixing -Wtype-limits warnings with the asserts (the expression would always evaluate to true). Also fixing a -Wcast-qual warning, where the cast expression isn't required.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221888 91177308-0d34-0410-b5e6-96231b3b80d8

Fixing some sign comparison warnings from MSVC; NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221887 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Create the Metadata class

This will become the root of a new class hierarchy separate from
`Value`.  As a first step, stick it between `Value` and `MDNode`.

This is part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221886 91177308-0d34-0410-b5e6-96231b3b80d8

AVX-512: SINT_TO_FP cost model and some bugfixes
Checked some corner cases, for example translation
of <8 x i1> to <8 x double>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221883 91177308-0d34-0410-b5e6-96231b3b80d8

Object, COFF: Refactor code to get relocation iterators

No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221880 91177308-0d34-0410-b5e6-96231b3b80d8

OCAMLFLAGS can contain =, don't use = with sed

Like HOST_LDFLAGS, etc. OCAMLFLAGS can contain =, so use ! as the substitution
separator instead of = (otherwise, sed might error).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221879 91177308-0d34-0410-b5e6-96231b3b80d8

This patch changes the ownership of TLOF from TargetLoweringBase to TargetMachine so that different subtargets could share the TLOF effectively

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221878 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r219432 - "Revert "[BasicAA] Revert "Revert r218714 - Make better use of zext and sign information."""

Let's try this again...

This reverts r219432, plus a bug fix.

Description of the bug in r219432 (by Nick):

The bug was using AllPositive to break out of the loop; if the loop break
condition i != e is changed to i != e && AllPositive then the
test_modulo_analysis_with_global test I've added will fail as the Modulo will
be calculated incorrectly (as the last loop iteration is skipped, so Modulo
isn't updated with its Scale).

Nick also adds this comment:

ComputeSignBit is safe to use in loops as it takes into account phi nodes, and
the  == EK_ZeroEx check is safe in loops as, no matter how the variable changes
between iterations, zero-extensions will always guarantee a zero sign bit. The
isValueEqualInPotentialCycles check is therefore definitely not needed as all
the variable analysis holds no matter how the variables change between loop
iterations.

And this patch also adds another enhancement to GetLinearExpression - basically
to convert ConstantInts to Offsets (see test_const_eval and
test_const_eval_scaled for the situations this improves).

Original commit message:

This reverts r218944, which reverted r218714, plus a bug fix.

Description of the bug in r218714 (by Nick):

The original patch forgot to check if the Scale in VariableGEPIndex flipped the
sign of the variable. The BasicAA pass iterates over the instructions in the
order they appear in the function, and so BasicAliasAnalysis::aliasGEP is
called with the variable it first comes across as parameter GEP1. Adding a
%reorder label puts the definition of %a after %b so aliasGEP is called with %b
as the first parameter and %a as the second. aliasGEP later calculates that %a
== %b + 1 - %idxprom where %idxprom >= 0 (if %a was passed as the first
parameter it would calculate %b == %a - 1 + %idxprom where %idxprom >= 0) -
ignoring that %idxprom is scaled by -1 here lead the patch to incorrectly
conclude that %a > %b.

Revised patch by Nick White, thanks! Thanks to Lang to isolating the bug.
Slightly modified by me to add an early exit from the loop and avoid
unnecessary, but expensive, function calls.

Original commit message:

Two related things:

 1. Fixes a bug when calculating the offset in GetLinearExpression. The code
    previously used zext to extend the offset, so negative offsets were converted
    to large positive ones.

 2. Enhance aliasGEP to deduce that, if the difference between two GEP
    allocations is positive and all the variables that govern the offset are also
    positive (i.e. the offset is strictly after the higher base pointer), then
    locations that fit in the gap between the two base pointers are NoAlias.

Patch by Nick White!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221876 91177308-0d34-0410-b5e6-96231b3b80d8

Object, COFF: Increase code reuse

Split getObject's smarts into checkOffset, use this to replace the
handwritten check in getSectionContents.  Similarly, replace checks in
section_rel_begin/section_rel_end with getNumberOfRelocations.

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221873 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-readobj: relocAddressLess could potentially lie

On error conditions, relocAddressLess might claim that a value is less
than itself.  Instead, abort llvm-readobj.  No functionality change
intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221872 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-readobj, COFF: Remove an unused variable

printRelocation doesn't use the section contents.  No functionality
change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221871 91177308-0d34-0410-b5e6-96231b3b80d8

Object, COFF: getRelocationSymbol shouldn't assert

lib/Object is supposed to be robust to malformed object files.  Don't
assert if we don't have a symbol table.  I'll try to come up with a test
case later.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221870 91177308-0d34-0410-b5e6-96231b3b80d8

Object, COFF: Cleanup some code in getSectionName

Use StringRef::startswith to tidy up some code, no functionality change
intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221869 91177308-0d34-0410-b5e6-96231b3b80d8

Object, COFF: Fix some theoretical bugs

getObject didn't consider the case where a pointer came before the start
of the object file.  No test is included, trying to come up with
something reasonable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221868 91177308-0d34-0410-b5e6-96231b3b80d8

Object, COFF: Clean up formatting in hasExtendedRelocations

No functionality changed intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221867 91177308-0d34-0410-b5e6-96231b3b80d8

Read 64 bits at a time in the bitcode reader.

The reading of 64 bit values could still be optimized, but at least this cuts
down on the number of virtual calls to fetch more data.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221865 91177308-0d34-0410-b5e6-96231b3b80d8

Update \param(s) in MemoryObject::readBytes(). [-Wdocumentation]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221863 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Teach the vector shuffle lowering to make a more nuanced decision
between splitting a vector into 128-bit lanes and recombining them vs.
decomposing things into single-input shuffles and a final blend.

This handles a large number of cases in AVX1 where the cross-lane
shuffles would be much more expensive to represent even though we end up
with a fast blend at the root. Instead, we can do a better job of
shuffling in a single lane and then inserting it into the other lanes.

This fixes the remaining bits of Halide's regression captured in PR21281
for AVX1. However, the bug persists in AVX2 because I've made this
change reasonably conservative. The cases where it makes sense in AVX2
to split into 128-bit lanes are much more rare because we can often do
full permutations across all elements of the 256-bit vector. However,
the particular test case in PR21281 is an example of one of the rare
cases where it is *always* better to work in a single 128-bit lane. I'm
going to try to teach the logic to detect and form the good code even in
AVX2 next, but it will need to use a separate heuristic.

Finally, there is one pesky regression here where we previously would
craftily use vpermilps in AVX1 to shuffle both high and low halves at
the same time. We no longer pull that off, and not for any really good
reason. Ultimately, I think this is just another missing nuance to the
selection heuristic that I'll try to add in afterward, but this change
already seems strictly worth doing considering the magnitude of the
improvements in common matrix math shuffle patterns.

As always, please let me know if this causes a surprising regression for
you.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221861 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-readobj: Print out address table when dumping COFF delay-import table

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221855 91177308-0d34-0410-b5e6-96231b3b80d8

Add an assert and a test that verify r221709's fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221854 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Don't form overly fragmented blends when splitting and
re-combining shuffles because nothing was available in the wider vector
type.

The key observation (which I've put in the comments for future
maintainers) is that at this point, no further combining is really
possible. And so even though these shuffles trivially could be combined,
we need to actually do that as we produce them when producing them this
late in the lowering.

This fixes another (huge) part of the Halide vector shuffle regressions.
As it happens, this was already well covered by the tests, but I hadn't
noticed how bad some of these got. The specific patterns that turn
directly into unpckl/h patterns were occurring *many* times in common
vector processing code.

There are still more problems here sadly, but trying to incrementally
tease them apart and it looks like this is the core of the problem in
the splitting logic.

There is some chance of regression here, you can see it in the test
changes. Specifically, where we stop forming pshufb in some cases, it is
possible that pshufb was in fact faster. Intel "says" that pshufb is
slower than the instruction sequences replacing it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221852 91177308-0d34-0410-b5e6-96231b3b80d8

[CodeGenPrepare] Handle zero extensions in the TypePromotionHelper.

Prior to this patch the TypePromotionHelper was promoting only sign extensions.
Supporting zero extensions changes:
- How constants are extended.
- How sign extensions, zero extensions, and truncate are composed together.
- How the type of the extended operation is recorded. Now we need to know the
  kind of the extension as well as its type.

Each change is fairly small, unlike the diff.
Most of the diff are comments/variable renaming to say "extension" instead of
"sign extension".

The performance improvements on the test suite are within the noise.

Related to <rdar://problem/18310086>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221851 91177308-0d34-0410-b5e6-96231b3b80d8

CMake: stop setting (well, #undef'ing) HOST_LINK_VERSION; it's used in Clang, not LLVM

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221849 91177308-0d34-0410-b5e6-96231b3b80d8

[FastISel][AArch64] Optimize select when one of the operands is a 'true' or 'false' value.

Optimize selects of i1 in the presence of 'true' and 'false' operands to simple
logic operations.

This fixes rdar://problem/18960150.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221848 91177308-0d34-0410-b5e6-96231b3b80d8

[FastISel][AArch64] Fold the cmp into the select when possible.

This folds the compare emission into the select emission when possible, so we
can directly use the flags and don't have to emit a separate compare.

Related to rdar://problem/18960150.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221847 91177308-0d34-0410-b5e6-96231b3b80d8

[FastISel][AArch64] Extend 'select' lowering to support also i1 to i16.

Related to rdar://problem/18960150.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221846 91177308-0d34-0410-b5e6-96231b3b80d8

Drop a few unneeded ctor calls (missed code review comment).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221845 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "[dwarfdump] Add support for dumping accelerator tables."

This reverts commit r221836.

The tests are asserting on some buildbots. This also reverts the
test part of r221837 as it relies on dwarfdump dumping the
accelerator tables.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221842 91177308-0d34-0410-b5e6-96231b3b80d8

Improve long path name support on Windows.

Windows normally limits the length of an absolute path name to 260
characters; directories can have lower limits.  These limits increase
to about 32K if you use absolute paths with the special '\\?\'
prefix. Teach Support\Windows\Path.inc to use that prefix as needed.

TODO: Other parts of Support could also learn to use this prefix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221841 91177308-0d34-0410-b5e6-96231b3b80d8

[Bitcode] AtEndOfStream should only check against the size if it's known.

This avoids an issue where AtEndOfStream mistakenly returns true at the /start/ of
a stream.

(In the rare case that the size is known and actually 0, the slow path will still
handle it correctly.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221840 91177308-0d34-0410-b5e6-96231b3b80d8

Teach ScalarEvolution to sharpen range information.

If x is known to have the range [a, b), in a loop predicated by (icmp
ne x, a) its range can be sharpened to [a + 1, b).  Get
ScalarEvolution and hence IndVars to exploit this fact.

This change triggers an optimization to widen-loop-comp.ll, so it had
to be edited to get it to pass.

This change was originally landed in r219834 but had a bug and broke
ASan. It was reverted in r219878, and is now being re-landed after
fixing the original bug.

phabricator: http://reviews.llvm.org/D5639
reviewed by: atrick

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221839 91177308-0d34-0410-b5e6-96231b3b80d8

Fix emission of Dwarf accelerator table when there are multiple CUs.

The DIE offset in the accel tables is an offset relative to the start
of the debug_info section, but we were encoding the offset to the
start of the containing CU.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221837 91177308-0d34-0410-b5e6-96231b3b80d8

[dwarfdump] Add support for dumping accelerator tables.

The class used for the dump only allows to dump for the moment, but
it can (and will) be easily extended to support search also.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221836 91177308-0d34-0410-b5e6-96231b3b80d8

Allow DWARFFormValue::extractValue to be called with a null CU.

Currently FormValues are only used for attributes of DIEs and thus
uers always have a CU lying around when calling into the FormValue
API.
Accelerator tables encode their information using the same Forms
as the attributes, thus it is natural to use DWARFFormValue to
extract/dump them. There is no CU in that case though. Allow the
API to be called with a null CU arguemnt by making the RelocMap
lookup conditional on the CU pointer validity. And document this
new behvior in the header. (Test coverage for this use of the API
comes in the DwarfAccelTable support patch)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221835 91177308-0d34-0410-b5e6-96231b3b80d8

Remove unsused variables.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221834 91177308-0d34-0410-b5e6-96231b3b80d8

[CodeGenPrepare] Replace other uses of EVT::getEVT with TL::getValueType.

r221820 fixed a problem (PR21548) where an iPTR was used in TLI legality checks,
which isn't valid and resulted in a failed assertion.
The solution was to lower pointer types into the correct target's VT, by
using TL::getValueType instead of EVT::getEVT.

This commit changes 3 other uses of EVT::getEVT, but without any tests:
- One of these non-lowered EVTs is passed to allowsMisalignedMemoryAccesses,
which goes into target's TL implementation and doesn't cause any problem (yet.)
- Two others are passed to TLI.isOperationLegalOrCustom:
  - one only looks at extensions, so doesn't concern pointers.
  - one only looks at binary operators, so also isn't a problem.

The latter might some day be exposed to pointers and cause the same assert as
the original PR, because there's a comment hinting at also supporting cast ops.

For consistency, update all of them and be done with it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221827 91177308-0d34-0410-b5e6-96231b3b80d8

[CodeGenPrepare][AArch64] Fix a TLI legality check on iPTR to use a lowered instead.

Fixes PR21548.  Related to PR20474.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221820 91177308-0d34-0410-b5e6-96231b3b80d8

Expose the number of Newton-Raphson iterations applied to the hardware's reciprocal estimate as a parameter (x86).

This is a follow-on to r221706 and r221731 and discussed in more detail in PR21385.

This patch also loosens the testcase checking for btver2. We know that the "1.0" will be loaded, but
we can't tell exactly when, so replace the CHECK-NEXT specifiers with plain CHECKs. The CHECK-NEXT
sequence relied on a quirk of post-RA-scheduling that may change independently of anything in these tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221819 91177308-0d34-0410-b5e6-96231b3b80d8

Add fortified (__*_chk) library functions to TLI (NFC)

One of them (__memcpy_chk) was already there, the others were checked
by comparing function names.
Note that the fortified libfuncs are now part of TLI, but are always
available, because they aren't generated, only optimized into the
non-checking versions.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221817 91177308-0d34-0410-b5e6-96231b3b80d8

Temporary fix for PR21528 - use mangled C++ function names in COFF debug info to un-break ASan on Windows

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221813 91177308-0d34-0410-b5e6-96231b3b80d8

[COFF] Make it clearer that the symbols subsection holds function display name rather than just name

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221812 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX512] Add integer shift by immediate intrinsics.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221811 91177308-0d34-0410-b5e6-96231b3b80d8

Changing a StringRef::begin() call into StringRef::data(); NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221808 91177308-0d34-0410-b5e6-96231b3b80d8

Use the return of readBytes to find out if we are at the end of the stream.

This allows the removal of isObjectEnd and opens the way for reading 64 bits
at a time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221804 91177308-0d34-0410-b5e6-96231b3b80d8

CGSCC should not treat intrinsic calls like function calls (PR21403)

Make the handling of calls to intrinsics in CGSCC consistent:
they are not treated like regular function calls because they
are never lowered to function calls.

Without this patch, we can get dangling pointer asserts from
the subsequent loop that processes callsites because it already
ignores intrinsics.

See http://llvm.org/bugs/show_bug.cgi?id=21403 for more details / discussion.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221802 91177308-0d34-0410-b5e6-96231b3b80d8

Fix broken doxygen annotations, NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221801 91177308-0d34-0410-b5e6-96231b3b80d8

Disable indvar widening if arithmetics on the wider type are more expensive

Summary:
Reapply r221772. The old patch breaks the bot because the @indvar_32_bit test
was run whether NVPTX was enabled or not.

IndVarSimplify should not widen an indvar if arithmetics on the wider
indvar are more expensive than those on the narrower indvar. For
instance, although NVPTX64 treats i64 as a legal type, an ADD on i64 is
twice as expensive as that on i32, because the hardware needs to
simulate a 64-bit integer using two 32-bit integers.

Split from D6188, and based on D6195 which adds NVPTXTargetTransformInfo.

Fixes PR21148.

Test Plan:
Added @indvar_32_bit that verifies we do not widen an indvar if the arithmetics
on the wider type are more expensive. This test is run only when NVPTX is
enabled.

Reviewers: jholewinski, eliben, meheff, atrick

Reviewed By: atrick

Subscribers: jholewinski, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221799 91177308-0d34-0410-b5e6-96231b3b80d8

remove function names from comments; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221798 91177308-0d34-0410-b5e6-96231b3b80d8