[Orc][Kaleidoscope] Clean up the Orc/Kaleidoscope tutorials to minimize the diffs
between them.

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

LowerBitSets: Align referenced globals.

This change aligns globals to the next highest power of 2 bytes, up to a
maximum of 128. This makes it more likely that we will be able to compress
bit sets with a greater alignment. In many more cases, we can now take
advantage of a new optimization also introduced in this patch that removes
bit set checks if the bit set is all ones.

The 128 byte maximum was found to provide the best tradeoff between instruction
overhead and data overhead in a recent build of Chromium. It allows us to
remove ~2.4MB of instructions at the cost of ~250KB of data.

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

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

[CMake] Fix the clang-cl self host build.

This allows clang-cl to self-host cleanly with no magic setup
steps required.

After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.

These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.

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

Fixing a problem with insert location in WinEH outlining

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

Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap

(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).

When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.

This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.

Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.

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

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

[PowerPC] Cleanup unused target-specific SDAG nodes

We had somehow accumulated a few target-specific SDAG nodes dealing with PPC64
TOC access that were referenced only in TableGen patterns. The associated
(pseudo-)instructions are used, but are being generated directly. NFC.

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

AArch64: Add debug message for large shift constants.

As requested in code review.

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

Fix really obscure bug in CannotBeNegativeZero() (PR22688)

With a diabolically crafted test case, we could recurse
through this code and return true instead of false.

The larger engineering crime is the use of magic numbers.
Added FIXME comments for those.

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

fix a typo

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

[MIPS]Multiple and add instructions for Mips are currently available in mips32r2/mips64r2 and later but should also be available in mips4, mips5, and mips64. This patch fixes the requested features and updates the corresponding test files.

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

[X86][MMX] Reapply: Add MMX instructions to foldable tables

Reapply r230248.

Teach the peephole optimizer to work with MMX instructions by adding
entries into the foldable tables. This covers folding opportunities not
handled during isel.

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

[X86][MMX] Prevent MMX_MOVD64rm folding

MMX_MOVD64rm zero-extends i32 load results into i64 registers.

The peephole optimizer will try to fold it in other MMX foldable
instructions, the wrong thing to do, since there's no MMX memory
instruction that loads from i32 and does implict zero extension.

Remove 'canFoldAsLoad' from MOVD64rm in order to prevent such folding.
The current MMX tests already test this, but since there are no MMX
instructions in the foldable tables yet, this did not trigger. This
commit prepares the addition of those instructions.

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

Improve handling of stack accesses in Thumb-1

Thumb-1 only allows SP-based LDR and STR to be word-sized, and SP-base LDR,
STR, and ADD only allow offsets that are a multiple of 4. Make some changes
to better make use of these instructions:

* Use word loads for anyext byte and halfword loads from the stack.
* Enforce 4-byte alignment on objects accessed in this way, to ensure that
  the offset is valid.
* Do the same for objects whose frame index is used, in order to avoid having
  to use more than one ADD to generate the frame index.
* Correct how many bits of offset we think AddrModeT1_s has.

Patch by John Brawn.

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

Silencing a "result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)" warning in MSVC; NFC.

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

Silencing a -Wsign-compare warning triggered in MSVC; NFC.

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

Replace obsolete -mattr=n64 command line option with -target-abi=n64. No functional changes.

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

GlobalLayoutBuilder::addFragment(): Prune incorrect usage of \param(s). [-Wdocumentation]

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

Fix UTF8 chars to ASCII.

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

AVX-512: Gather and Scatter patterns
Gather and scatter instructions additionally write to one of the source operands - mask register.
In this case Gather has 2 destination values - the loaded value and the mask.
Till now we did not support code gen pattern for gather - the instruction was generated from
intrinsic only and machine node was hardcoded.
When we introduce the masked_gather node, we need to select instruction automatically,
in the standard way.
I added a flag "hasTwoExplicitDefs" that allows to handle 2 destination operands.

(Some code in the X86InstrFragmentsSIMD.td is commented out, just to split one big
patch in many small patches)

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

[IC] Turn non-null MD on pointer loads to range MD on integer loads.

Summary:
This change fixes the FIXME that you recently added when you committed
(a modified version of) my patch.  When `InstCombine` combines a load and
store of an pointer to those of an equivalently-sized integer, it currently
drops any `!nonnull` metadata that might be present.  This change replaces
`!nonnull` metadata with `!range !{ 1, -1 }` metadata instead.

Reviewers: chandlerc

Subscribers: llvm-commits

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

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

Add some missing #includes and forward declarations found by modules build.

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

build: check if atomic routines are implicitly provided

It is possible for the atomic routines to be provided by the compiler without
requiring any additional libraries.  Check if that is the case before checking
for a library.

Patch by Matt Glazar!

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

[modules] Add include/llvm/IR/DebugInfoFlags.def to the textual headers list.

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

[PowerPC] Add triples to QPX tests

Some of these tests fail on Darwin systems because of a lack of a triple;
fix that.

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

[GC] Document the recently added PlaceSafepoints and RewriteGCForStatepoints passes

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

llvm-dis: Stop crashing when dropping debug info

Since r199356, we've printed a warning when dropping debug info.
r225562 started crashing on that, since it registered a diagnostic
handler that only expected errors.  This fixes the handler to expect
other severities.  As a side effect, it now prints "error: " at the
start of error messages, similar to `llvm-as`.

There was a testcase for r199356, but it only really checked the
assembler.  Move `test/Bitcode/drop-debug-info.ll` to `test/Assembler`,
and introduce `test/Bitcode/drop-debug-info.3.5.ll` (and companion
`.bc`) to test the bitcode reader.

Note: tools/gold/gold-plugin.cpp has an equivalent bug, but I'm not sure
what the best fix is there.  I'll file a PR.

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

[opaque pointer type] Bitcode support for explicit type parameter on GEP.

Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

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

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

[opaque pointer type] bitcode support for explicit type parameter to the load instruction

Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections would be great.

This seems to pass all the tests (check-all, covering clang and llvm) so I
believe that pretty well exercises both the backwards compatibility and common
(same version) compatibility given the number of checked in bitcode files we
already have. Is that a reasonable approach to testing here? Would some more
explicit tests be desired?

1) is this the right way to do back-compat in this case (looking at the number
  of entries in the bitcode record to disambiguate between the old schema and
  the new?)

2) I don't quite understand the logarithm logic to choose the encoding type of
  the type parameter in the abbreviation description, but I found another
  instruction doing the same thing & it seems to work. Is that the right
  approach?

Reviewers: dexonsmith

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

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

[PowerPC] Add support for the QPX vector instruction set

This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially  { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).

I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).

The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.

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

Support SHF_MERGE sections in COMDATs.

This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions from the non-comdat side.

In ELF there is no one true section for "4 byte mergeable" constants.
We are better off computing the required properties of the section
and asking the context for it.

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

BitcodeWriter: Refactor common computation of bits required for a type index.

Suggested by Duncan. Happy to bikeshed the name, cache the result, etc.

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

Fix consistently wrong sphinx markup

I'd been using '' where I should have been using ``.

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

Update the GC docs to explicitly mention both gcroot and gc.statepoint

Also, fix confusing bit of the gcroot documentation that bit me personally.

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

Make this test even more OS and register allocation neutral.

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

[GC] Sync documentation with code naming

Fixing an issue pointed out by Sean Silva.  Thanks!

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

More GC documentation cleanup

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

Make this test not dependent upon the triple. All that was needed
was some flexibility in the check line for the comment basic block.

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

More GC doc cleanup

Mostly minor wording changes for readability.  Nothing major to see here.

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

[CMake] Set policy CMP0051 to OLD globally.

When you use generator expressions in a library sources list,
and then later access the SOURCES property, the OLD behavior
(CMake 3.0 and earlier) would not include these expressions in
the SOURCES property.  The NEW behavior (starting in CMake 3.1)
is that they do include the generator expressions in the SOURCES
property.

Differential Revision: http://reviews.llvm.org/D7870
Reviewed By: Chris Bieneman

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

LowerBitSets: Introduce global layout builder.

The builder is based on a layout algorithm that tries to keep members of
small bit sets together. The new layout compresses Chromium's bit sets to
around 15% of their original size.

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

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

Improve the getting started instructions in the GC docs

This is still gcroot vs gc.statepoint agnostic.  I'm just trying to clarify the general documentation at this point.

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

PrologEpilogInserter: Clean up math in calculateFrameObjectOffsets

There is no need to open-code the alignment calculation, we have a
handy RoundUpToAlignment function which "Does The Right Thing (TM)".

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

remove function names from comments; NFC

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

Reapplied D7816 & rL230177 & rL230278 - with an additional fix toensure that the smallest build vector input scalar type is always used. Additional (crash) test cases already committed.

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

Added test case for PR22678 (check CONCAT_VECTORS DAG combiner pass doesn't introduce illegal types)

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

InstrProf: Test for appropriate linkage of the profiling structures

This test checks that the symbols instrprof creates have appropriate
linkage. The tests already exist in clang in a slightly different form
from before we sunk profile generation into an LLVM pass, but that's
an awkward place for them now. I'll remove/simplify the clang versions
shortly.

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

Fixing eol-style

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

ReleaseNotes: add notes about VS2014 Update 4 requirement

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

Fix typo: qual -> equal

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

Starting to cleanup the garbage collection documentation

In this change:
- Put the getting started section first
- Create a dedicated section to document the built in collector strategies
- Move discuss of ShadowStack into new section
- Add placeholders for erlang, ocaml, and statepoint-example collectors

There will be many more changes following.  I plan on full integrating the documentation for gc.statepoint and gc.root.  I want to make it much clearer on how to get started and what users should expect in terms of effort.

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

Revert:

Author: Simon Pilgrim <llvm-dev@redking.me.uk>
Date:   Mon Feb 23 23:04:28 2015 +0000

    Fix based on post-commit comment on D7816 & rL230177 - BUILD_VECTOR operand truncation was using the the BV's output scalar type instead of the input type.

and

Author: Simon Pilgrim <llvm-dev@redking.me.uk>
Date:   Sun Feb 22 18:17:28 2015 +0000

    [DagCombiner] Generalized BuildVector Vector Concatenation

    The CONCAT_VECTORS combiner pass can transform the concat of two BUILD_VECTOR nodes into a single BUILD_VECTOR node.

    This patch generalises this to support any number of BUILD_VECTOR nodes, and also permits UNDEF nodes to be included as well.

    This was noticed as AVX vec128 -> vec256 canonicalization sometimes creates a CONCAT_VECTOR with a real vec128 lower and an vec128 UNDEF upper.

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

as the root cause of PR22678 which is causing an assertion inside the DAG combiner.

I'll follow up to the main thread as well.

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

Rename UpdateRegAllocHint to match style guidelines.

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

AArch64: Relax assert about large shift sizes.

The reason why these large shift sizes happen is because OpaqueConstants
currently inhibit alot of DAG combining, but that has to be addressed in
another commit (like the proposal in D6946).

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

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

DAGCombiner: Move variable definitions closer to use; NFC

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

DAGCombiner: Move variable declaration closer to definiion; NFC

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

R600/SI: Remove isel mubuf legalization

We legalize mubuf instructions post-instruction selection, so this
code is no longer needed.

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

ARM: treat [N x i32] and [N x i64] as AAPCS composite types

The logic is almost there already, with our special homogeneous aggregate
handling. Tweaking it like this allows front-ends to emit AAPCS compliant code
without ever having to count registers or add discarded padding arguments.

Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to
apply the logic to all integer arrays for more consistency.

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

Revert "Raising minimum required CMake version to 2.8.12.2."

This reverts commit r230062.

Debian stable (wheezy) ships still with cmake 2.8.9.

The commit broke my LLVM/Polly buildbot, to my knowledge our only Linux+cmake
buildbot.

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

simplify control flow; NFC

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

Revert r230280: "Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap"

This caused PR22674, failing this assert:

Instructions.h:2281: llvm::Value* llvm::PHINode::getOperand(unsigned int) const: Assertion `i_nocapture < OperandTraits<PHINode>::operands(this) && "getOperand() out of range!"' failed.

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

[x32] Mark RBX as reserved when EBX is the base pointer.

This should have gone into r230334.

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

fix typo in comment; NFC

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

[x32] x32 should use ebx as the base pointer.

This fixes the original issue in PR22655, but not the secondary one.

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

[SDAG] Handle LowerOperation returning its input consistently

For almost all node types, if the target requested custom lowering, and
LowerOperation returned its input, we'd treat the original node as legal. This
did not work, however, for many loads and stores, because they follow
slightly different code paths, and we did not account for the possibility of
LowerOperation returning its input at those call sites.

I think that we now handle this consistently everywhere. At the call sites in
LegalizeDAG, we used to assert in this case, so there's no functional change
for any existing code there. For the call sites in LegalizeVectorOps, this
really only affects whether or not we set Changed = true, but I think makes the
semantics clearer.

No test case here, but it will be covered by an upcoming PowerPC commit adding
QPX support.

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

[mips] Reformat some TableGen definitions. NFC.

Summary: Separated some instruction and pseudo-instruction definitions from InstAlias definitions, added banner for pseudo-instructions and removed a redundant whitespace from a pseudo-instruction definition. No functional change.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

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

Fix alloca_instruments_all_paddings.cc test to work under higher -O levels (llvm part)

When AddressSanitizer only a single dynamic alloca and no static allocas, due to an early exit from FunctionStackPoisoner::poisonStack we forget to unpoison the dynamic alloca.  This patch fixes that.

Reviewed at http://reviews.llvm.org/D7810

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

[X86] Remove the AbsMem32 type from the assembly parser. Only really need the 16-bit version which will automatically get prioritized over AbsMem.

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

Beginning of alloca implementation for Mips fast-isel

Summary: Begin to add various address modes; including alloca.

Test Plan: Make sure there are no regressions in test-suite at O0/02 in mips32r1/r2

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: echristo, rfuhler, llvm-commits

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

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

Fix handling of negative offsets for AddrModeT2_i8s4 in rewriteT2FrameIndex.

This is a follow up to r230233 to fix something that I noticed by
inspection. The AddrModeT2_i8s4 addressing mode does not support
negative offsets. I spent a good chunk of the day trying to come up with
a testcase for this but was not successful. This addressing mode is used
to spill and restore GPRPair registers in Thumb2 code and that does not
happen often. We also make very limited used of negative offsets when
lowering frame indexes. I am going ahead with the change anyway, because
I am pretty confident that it is correct. I also added a missing assertion
to check that the low bits of the scaled offset are zero.

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

Fix bug 22641

The bug was a result of getPreStartForExtend interpreting nsw/nuw
flags on an add recurrence more strongly than is legal.  {S,+,X}<nsw>
implies S+X is nsw only if the backedge of the loop is taken at least
once.

NOTE: I had accidentally committed an unrelated change with the commit
message of this change in r230275 (r230275 was reverted in r230279).
This is the correct change for this commit message.

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

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

[LTO API] add lto_codegen_set_module to set the destination module.

When debugging LTO issues with ld64, we use -save-temps to save the merged
optimized bitcode file, then invoke ld64 again on the single bitcode file to
speed up debugging code generation passes and ld64 stuff after code generation.

llvm linking a single bitcode file via lto_codegen_add_module will generate a
different bitcode file from the single input. With the newly-added
lto_codegen_set_module, we can make sure the destination module is the same as
the input.

lto_codegen_set_module will transfer the ownship of the module to code
generator.

rdar://19024554

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

[LoopAccesses] LAA::getInfo to use const reference for stride parameter

And other required const-correctness fixes to make this work.

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

X86: Only use 'lea' in Win64 epilogues if a frame pointer exists

We can only use 'add' in epilogues, 'lea' is not permitted unless we've
established a frame pointer in the prologue.

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

New instcombine rule: max(~a,~b) -> ~min(a, b)

This case is interesting because ScalarEvolutionExpander lowers min(a,
b) as ~max(~a,~b).  I think the profitability heuristics can be made
more clever/aggressive, but this is a start.

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

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

Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap

When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.

This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.

Apart from the attached test case, another (more realistic) manifestation
of the bug can be seen in Transforms/IndVarSimplify/pr20680.ll.

NOTE: this change was landed with an incorrect commit message in
rL230275 and was reverted for that reason in rL230279.  This commit
message is the correct one.

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

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

Revert 230275.

230275 got committed with an incorrect commit message due to a mixup
on my side.  Will re-land in a few moments with the correct commit
message.

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

Fix based on post-commit comment on D7816 & rL230177 - BUILD_VECTOR operand truncation was using the the BV's output scalar type instead of the input type.

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

[X86] Teach how to custom lower double-to-half conversions under fast-math.

This patch teaches the backend how to expand a double-half conversion into
a double-float conversion immediately followed by a float-half conversion.
We do this only under fast-math, and if float-half conversions are legal
for the target.

Added test CodeGen/X86/fastmath-float-half-conversion.ll

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

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

Fix bug 22641

The bug was a result of getPreStartForExtend interpreting nsw/nuw
flags on an add recurrence more strongly than is legal.  {S,+,X}<nsw>
implies S+X is nsw only if the backedge of the loop is taken at least
once.

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

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

Fix invalid cast.

Fixes PR22525.

Patch by Ben Longbons with testcase by me.

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

X86: Use a smaller 'mov' instruction for stack probe calls

Prologue emission, in some cases, requires calls to a stack probe helper
function.  The amount of stack to probe is passed as a register
argument in the Win64 ABI but the instruction sequence used is
pessimistic: it assumes that the number of bytes to probe is greater
than 4 GB.

Instead, select a more appropriate opcode depending on the number of
bytes we are going to probe.

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

X86: Use 'mov' instead of 'lea' in Win64 SEH prologues when possible

'mov' and 'lea' are equivalent when the displacement applied with 'lea'
is zero.  However, 'mov' should encode smaller.

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

X86: Explain why we cannot use a 'mov' in a Win64 epilogue

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

X86: Consistently use 'epilogue' instead of 'epilog'

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

add newline for easier reading; NFC

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

[AsmPrinter] Access pointers to globals via pcrel GOT entries

Front-ends could use global unnamed_addr to hold pointers to other
symbols, like @gotequivalent below:

@foo = global i32 42
@gotequivalent = private unnamed_addr constant i32* @foo

@delta = global i32 trunc (i64 sub (i64 ptrtoint (i32** @gotequivalent to i64),
                                    i64 ptrtoint (i32* @delta to i64))
                           to i32)

The global @delta holds a data "PC"-relative offset to @gotequivalent,
an unnamed pointer to @foo. The darwin/x86-64 assembly output for this follows:

 .globl  _foo
_foo:
 .long   42

 .globl  _gotequivalent
_gotequivalent:
 .quad   _foo

 .globl  _delta
_delta:
 .long   _gotequivalent-_delta

Since unnamed_addr indicates that the address is not significant, only
the content, we can optimize the case above by replacing pc-relative
accesses to "GOT equivalent" globals, by a PC relative access to the GOT
entry of the final symbol instead. Therefore, "delta" can contain a pc
relative relocation to foo's GOT entry and we avoid the emission of
"gotequivalent", yielding the assembly code below:

 .globl  _foo
_foo:
 .long   42

 .globl  _delta
_delta:
 .long   _foo@GOTPCREL+4

There are a couple of advantages of doing this: (1) Front-ends that need
to emit a great deal of data to store pointers to external symbols could
save space by not emitting such "got equivalent" globals and (2) IR
constructs combined with this opt opens a way to represent GOT pcrel
relocations by using the LLVM IR, which is something we previously had
no way to express.

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

rdar://problem/18534217

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

InstrProf: Teach llvm-cov to show the max count instead of the last

When multiple regions start on the same line, llvm-cov was just
showing the count of the last one as the line count. This can be
confusing and misleading for things like one-liner loops, where the
count at the end isn't very interesting, or even "if" statements with
an opening brace at the end of the line.

Instead, use the maximum of all of the region start counts.

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

Removing unused private field.

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

[X86][MMX] Fix test to reflect current codegen

This test failed in several buildbots, a bit unclear how that happen
since this was the previous behavior before r230248.

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

Second attempt to fix WinEHCatchDirector build failures.

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

Attempting to fix WinEHCatchDirector destructor related build failures.

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

Adding test for Windows EH frame variable remapping.

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

Remap frame variables for native Windows exception handling.

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

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

Revert "[X86][MMX] Add MMX instructions to foldable tables"

This reverts commit r230226 since it breaks win buildbots.

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

Revert "Revert "Raising minimum required CMake version to 2.8.12.2.""

This reverts commit r230240, which was an accidental commit.

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

Rewrite the global merge pass to be subprogram agnostic for now.
It was previously using the subtarget to get values for the global
offset without actually checking each function as it was generating
code. Go ahead and solidify the current behavior and make the
existing FIXMEs more prominent.

As a note the ARM backend previously had a thumb1 and non-thumb1
set of defaults. Only the former was tested so I've changed the
behavior to only use that for now.

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

Prevent hoisting fmul from THEN/ELSE to IF if there is fmsub/fmadd opportunity.

This patch adds the isProfitableToHoist API.  For AArch64, we want to prevent a
fmul from being hoisted in cases where it is more profitable to form a
fmsub/fmadd.

Phabricator Review: http://reviews.llvm.org/D7299
Patch by Lawrence Hu <lawrence@codeaurora.org>

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

Revert "Raising minimum required CMake version to 2.8.12.2."

This reverts commit 247aed4710e8befde76da42b27313661dea7cf66.

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

cmake: Don't do the libstdc++ version check when clang simulates MSVC

If we're using clang-cl, that's a pretty good indication that we're
going to use MSVC's STL.

This simplifies the clang-cl ninja self-host configuration down to:
CC=clang-cl CXX=clang-cl cmake .. -GNinja

Modified version of zturner's patch:
Differential Revision: http://reviews.llvm.org/D7824

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

InstSimplify: simplify 0 / X if nnan and nsz

From: Fiona Glaser <fglaser@apple.com>

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