IR: Split up Constant{Array,Vector}::get(), NFC

Introduce `getImpl()` that tries the simplification logic from `get()`
and then gives up.  This allows the logic to be reused elsewhere in a
follow-up commit.

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

[X86, X87 stackifier] Do not mark an operand of a debug instruction as kill.

<rdar://problem/16952634>

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

IR: Reduce RAUW traffic in ConstantExpr

Avoid RAUW-ing `ConstantExpr` when an operand changes unless the new
`ConstantExpr` already has users.  This prevents the RAUW from rippling
up the expression tree unnecessarily.

This commit indirectly adds test coverage for r215953 (this is how I
came across the bug).

This is part of PR20515.

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

IR: Replace uses of ConstantAggrUniqueMap with ConstantUniqueMap

Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same
way, change the aggregates to use the new one.

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

Remove extraneous typenames from r215957

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

IR: Rewrite ConstantUniqueMap

Rewrite `ConstantUniqueMap` to be more similar to
`ConstantAggrUniqueMap`.

  - Use a `DenseMap` with custom MapInfo instead of a `std::map` with
    linear lookups and deletion.
  - Don't waste memory explicitly storing (heavyweight) keys.

Only `ConstantExpr` and `InlineAsm` actually use this data structure, so
I also updated them to use it.

This code cleanup is a precursor to reducing RAUW traffic on
`ConstantExpr` -- I felt badly adding a new (linear) call to
`ConstantUniqueMap::FindExistingKey`, so this designs away the concern.

A follow-up commit will transition the users of `ConstantAggrUniqueMap`
over.

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

IR: Declare LookupKey right before its use, NFC

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

IR: ArrayRef-ize {Insert,Extract}ValueConstantExpr constructors

No functionality change.

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

Prevent clang-format from moving the namespace closing brace, NFC

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

NVPTX: Use RAUW instead of reinventing the wheel

This code had a homemade RAUW that was incorrect when a user was a
constant: instead of calling `replaceUsersWithOnConstant()` it would
incorrectly update the operand in-place, invalidating
`LLVMContextImpl::ExprConstants`.  RAUW does the job better.

The ValueHandle that `GVMap` is holding onto needs to be removed first,
so this commit also removes each variable from the map on-the-fly.

Since deletions from `ExprConstants` use a linear search that compares
directly on the pointer value (instead of using the key), there isn't an
obvious way to expose this with a testcase.

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

LLParser: Handle BlockAddresses on-the-fly

Previously all `blockaddress()` constants were treated as forward
references.  They were resolved twice:  once at the end of the function
in question, and again at the end of the module.  Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).

Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references.  After the function, all references can be
resolved immediately.  To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.

Also, create only one forward-reference per basic block.  Because
forward references to block addresses are rare, the data structure here
shouldn't matter.  If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.

This is part of PR20515.

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

verify-uselistorder: Call verifyModule() and improve output

Call `verifyModule()` after parsing and after every transformation.
Also convert some `DEBUG(dbgs())` to `errs()` to increase visibility
into what's going on.

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

Use a range loop. NFC.

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

These classes only need a StringRef, not a MemoryBuffer.

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

Delete unused method.

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

Answer to Philip Reames comments

- add check for volatile (probably unneeded, but I agree that we should be conservative about it).
- strengthen condition from isUnordered() to isSimple(), as I don't understand well enough Unordered semantics (and it also matches the comment better this way) to be confident in the previous behaviour (thanks for catching that one, I had missed the case Monotonic/Unordered).
- separate a condition in two.
- lengthen comment about aliasing and loads
- add tests in GVN/atomic.ll

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

Weak relaxing of the constraints on atomics in MemoryDependencyAnalysis

Monotonic accesses do not have to kill the analysis, as long as the QueryInstr is not
itself atomic.

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

[MCJIT] Respect target endianness in RuntimeDyldMachO and RuntimeDyldChecker.

This patch may address some of the issues described in http://llvm.org/PR20640.

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

Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O
file with -macho, the Mach-O specific object file parser option.

After some discussion I chose to do this implementation contained in the logic
of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when
needed and with updates mostly contained in the MachOObjectFile class.

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

[X86][Haswell][SchedModel] Tidy up.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point XMM and YMM instructions.
Sub-group: Other instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point XMM and YMM instructions.
Sub-group: Logic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point XMM and YMM instructions.
Sub-group: Math instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point XMM and YMM instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point XMM and YMM instructions.
Sub-group: Conversion instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point XMM and YMM instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer MMX and XMM instructions.
Sub-group: Other instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer MMX and XMM instructions.
Sub-group: Logic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer MMX and XMM instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer MMX and XMM instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point x87 instructions.
Sub-group: Math instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point x87 instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Floating Point x87 instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: Other instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: Synchronization instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: String instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: Control transfer instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: Logic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

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

[X86][Haswell][SchedModel] Add architecture specific scheduling models.
Group: Integer instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

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

Make use of isAtLeastRelease/Acquire in the ARM/AArch64 backends

Summary:
Make use of isAtLeastRelease/Acquire in the ARM/AArch64 backends
These helper functions are introduced in D4844.
Depends D4844

Test Plan: make check-all passes

Reviewers: jfb

Subscribers: aemerson, llvm-commits, mcrosier, reames

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

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

Disabling an MSVC warning ('var' : definition from the for loop is ignored; the definition from the enclosing scope is used) which will trigger false positives more than true positives.

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

Teach the AArch64 backend to handle f16

This allows the AArch64 backend to handle fadd, fsub, fmul and fdiv
operations on f16 (half-precision) types by promoting to f32.

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

[ARM,AArch64] Do not tail-call to an externally-defined function with weak linkage

Externally-defined functions with weak linkage should not be
tail-called on ARM or AArch64, as the AAELF spec requires normal calls
to undefined weak functions to be replaced with a NOP or jump to the
next instruction. The behaviour of branch instructions in this
situation (as used for tail calls) is implementation-defined, so we
cannot rely on the linker replacing the tail call with a return.

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

AVX-512: Fixed a bug in emitting compare for MVT:i1 type.
Added a test.

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

Silencing an MSVC warning about loop variable conflicting with a variable from an outer scope. NFC.

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

TableGen: allow use of uint64_t for available features mask.

ARM in particular is getting dangerously close to exceeding 32 bits worth of
possible subtarget features. When this happens, various parts of MC start to
fail inexplicably as masks get truncated to "unsigned".

Mostly just refactoring at present, and there's probably no way to test.

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

Added forgotten noexcept.

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

Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size."

Getting a weird buildbot failure that I need to investigate.

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

Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.

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

Use copy initialization to initialize std::unique_ptr.

Thanks to David Blaikie for the suggestion.

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

ARM: mark missing functions from RTABI

Simply indicate the functions that are part of the runtime library that we do
not setup libcalls for.  This is merely for ease of identification.  NFC.

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

ARM: improve RTABI 4.2 conformance on Linux

The set of functions defined in the RTABI was separated for no real reason.
This brings us closer to proper utilisation of the functions defined by the
RTABI.  It also sets the ground for correctly emitting function calls to AEABI
functions on all AEABI conforming platforms.

The previously existing lie on the behaviour of __ldivmod and __uldivmod is
propagated as it is beyond the scope of the change.

The changes to the test are due to the fact that we now use the divmod functions
which return both the quotient and remainder and thus we no longer need to
invoke two functions on Linux (making it closer to EABI's behaviour).

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

ARM: whitespace

Whitespace fix, NFC.

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

Remove unused member variable.

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

Return a std::uinque_ptr. Every caller was already using one.

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

Convert an ownership comment with std::uinque_ptr.

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

Pass a std::uinque_ptr to ParseAssembly to make the ownership explicit. NFC.

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

getLazyIRModule always takes ownership. Make that explicit.

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

Return a std::unique_ptr to make the ownership explicit.

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

Don't repeat the function name in comments. NFC.

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

Don't repeat names in comments. NFC.

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

Revert: r215698 - Current implementation of c.cond.fmt instructions only accept default cc0 register...

It causes a number of regressions when -fintegrated-as is enabled. This happens
because there are codegen-only instructions that incorrectly uses the first
operand as the encoding for the $fcc register. The regressions do not occur when
-via-file-asm is also given.

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

ARM: correct toggling behaviour

This was a thinko.  The intent was to flip the explicit bits that need toggling
rather than all bits.  This would result in incorrect behaviour (which now is
tested).

Thanks to Nico Weber for pointing this out!

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

llvm-objdump: don't print relocations in non-relocatable files.

This matches the behavior of GNU objdump.

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

Remove a redundant "public:". NFC.

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

BumpPtrAllocator: remove 'no slabs allocated yet' check

We already handle the no-slabs case when checking whether the current slab
is large enough: if no slabs have been allocated, CurPtr and End are both 0.
alignPtr(0), will still be 0, and so "if (Ptr + Size <= End)" fails.

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

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

Add a non-templated ELFObjectFileBase class.

Use it to implement some ELF only virtual interfaces instead of using error
prone series of dyn_casts.

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

Fix an off-by-one bug in the target independent llvm-objdump.

It would prevent the display of a single byte instruction before a label.

Patch by Steve King!

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

Reverted last commit

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

Reverted last commit

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

Added a table for intrinsics on X86.
It should remove dosens of lines in handling instrinsics (in a huge switch) and give an easy way to add new intrinsics.
I did not completed to move al intrnsics to the table, I'll do this in the upcomming commits.

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

Remove an InstCombine that transformed patterns like (x * uitofp i1 y) to (select y, x, 0.0) when the multiply has fast math flags set.
While this might seem like an obvious canonicalization, there is one subtle problem with it.  The result of the original expression
is undef when x is NaN (remember, fast math flags), but the result of the select is always defined when x is NaN.  This means that the
new expression is strictly more defined than the original one.  One unfortunate consequence of this is that the transform is not reversible!
It's always legal to make increase the defined-ness of an expression, but it's not legal to reduce it.  Thus, targets that prefer the original
form of the expression cannot reverse the transform to recover it.  Another way to think of it is that the transform has lost source-level
information (the fast math flags), which is undesirable.

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

[x86] Fix an indentation goof in a prior commit. Should have re-run
clang-format.

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

[shuffle] Teach the shufflevector fuzzer to support fixed element types.

I'm using this to try to find more minimal test cases by re-fuzzing
within a specific domain once errors are found.

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

llvm/test/CodeGen/X86/fmul-combines.ll: Appease Windows x64. <4 x float> is passed by stack.

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

Fix fmul combines with constant splat vectors

Fixes things like fmul x, 2 -> fadd x, x

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

[x86] Teach lots of the new vector shuffle lowering to use UNPCK
instructions for blend operations at 128 bits. This was a serious hole
in our prior blend lowering.

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

InstCombine: Fix a potential bug in 0 - (X sdiv C)  -> (X sdiv -C)

While *most* (X sdiv 1) operations will get caught by InstSimplify, it
is still possible for a sdiv to appear in the worklist which hasn't been
simplified yet.

This means that it is possible for 0 - (X sdiv 1) to get transformed
into (X sdiv -1); dividing by -1 can make the transform produce undef
values instead of the proper result.

Sorry for the lack of testcase, it's a bit problematic because it relies
on the exact order of operations in the worklist.

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

InstCombine: Combine mul with div.

We can combne a mul with a div if one of the operands is a multiple of
the other:

%mul = mul nsw nuw %a, C1
%ret = udiv %mul, C2
  =>
%ret = mul nsw %a, (C1 / C2)

This can expose further optimization opportunities if we end up
multiplying or dividing by a power of 2.

Consider this small example:

define i32 @f(i32 %a) {
  %mul = mul nuw i32 %a, 14
  %div = udiv exact i32 %mul, 7
  ret i32 %div
}

which gets CodeGen'd to:

    imull       $14, %edi, %eax
    imulq       $613566757, %rax, %rcx
    shrq        $32, %rcx
    subl        %ecx, %eax
    shrl        %eax
    addl        %ecx, %eax
    shrl        $2, %eax
    retq

We can now transform this into:
define i32 @f(i32 %a) {
  %shl = shl nuw i32 %a, 1
  ret i32 %shl
}

which gets CodeGen'd to:

    leal        (%rdi,%rdi), %eax
    retq

This fixes PR20681.

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

arm asm: Let .fpu enable instructions, PR20447.

I'm not very happy with duplicating the fpu->feature mapping in ARMAsmParser.cpp
and in clang's driver. See the bug for a patch that doesn't do that, and the
review thread [1] for why this duplication exists.

1: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/231052.html

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

[LIT] Move display of unsupported and xfail tests to summary.

Summary:
This patch changes the way xfail and unsupported tests are displayed.
This output is only displayed when the --show-unsupported/--show-xfail flags are passed to lit.

Currently xfail/unsupported tests are printed during the run of the test-suite. I think its better to display this information during the summary instead.
This patch removes the printing of these tests from when they are run to the summary.

Reviewers: ddunbar, EricWF

Reviewed By: EricWF

Subscribers: llvm-commits

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

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

BitcodeReader: Only create one basic block for each blockaddress

Block address forward-references are implemented by creating a
`BasicBlock` ahead of time that gets inserted in the `Function` when
it's eventually encountered.

However, if the same blockaddress was used in two separate functions
that were parsed *before* the referenced function (and the blockaddress
was never used at global scope), two separate basic blocks would get
created, one of which would be forgotten creating invalid IR.

This commit changes the forward-reference logic to create only one basic
block (and always return the same blockaddress).

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

UseListOrder: Correctly count the number of uses

This is an off-by-one bug I found by inspection, which would only
trigger if the bitcode writer sees more uses of a `Value` than the
reader.  Since this is only relevant when an instruction gets upgraded
somehow, there unfortunately isn't a reasonable way to add test
coverage.

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

IR: Don't add inbounds to GEPs of extern_weak variables

Global variables that have `extern_weak` linkage may be null, so it's
incorrect to add `inbounds` when constant folding.

This also fixes a bug when parsing global aliases, whose forward
reference placeholders are global variables with `extern_weak` linkage.
If GEPs to these aliases are encountered before the alias itself, the
GEPs would incorrectly gain the `inbounds` keyword as well.

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

[DAGCombiner] Improve the folding of target independet shuffles to Undef.

When combining a pair of shuffle nodes, check if the combined shuffle mask is
trivially Undef. In case, immediately fold that pair of shuffles to Undef.

The lack of checks for undef masks was the root-cause of a poor-codegen bug
in the dag combiner.

Example:
  %1 = shufflevector <4 x i32> %A, <4 x i32> %B, <4 x i32> <i32 4, i32 1, i32 1, i32 6>
  %2 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32> <i32 0, i32 4, i32 1, i32 6>
  %3 = shufflevector <4 x i32> %2, <4 x i32> undef, <4 x i32> <i32 1, i32 5, i32 3, i32 3>

Before this patch, on x86 (with -mcpu=corei7) we failed to fold the entire
sequence to Undef value and therefore we generated:
  shufps $-123, %xmm1, $xmm0
  pshufd $-46, %xmm0, %xmm0

With this patch, the entire shuffle sequence is folded to Undef and no
shuffles are generated in the output assembly.

Added new test cases to test 'combine-vec-shuffle-5.ll'.

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

[PowerPC] Mark fixed-offset byvals as pointed-to by IR values

A byval object, even if allocated at a fixed offset (prescribed by the ABI) is
pointed to by IR values. Most fixed-offset stack objects are not pointed-to by
IR values, so the default is to assume this is not possible. However, we need
to override the default in this case (instruction scheduling can cause
miscompiles otherwise).

Fixes PR20280.

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

Make isAliased property for fixed-offset stack objects adjustable

We used to assume that any fixed-offset stack object was not aliased. This
meant that no IR value could point to the memory contained in such an object.
This is a reasonable default, but is not a universally-correct
target-independent fact. For example, on PowerPC (both Darwin and non-Darwin),
some byval arguments are allocated at fixed offsets by the ABI. These, however,
certainly can be pointed to by IR values. This change moves the 'isAliased'
logic out of FixedStackPseudoSourceValue and into MFI, and allows the isAliased
property to be overridden for fixed-offset objects.

This will be used by an upcoming commit to the PowerPC backend to fix PR20280.

No functionality change intended (the behavior of
FixedStackPseudoSourceValue::isAliased has been made more conservative for
callers that don't pass an MFI object, but I don't see any in-tree callers that
do that).

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

[PowerPC] Darwin byval arguments are not immutable

On PPC/Darwin, byval arguments occur at fixed stack offsets in the callee's
frame, but are not immutable -- the pointer value is directly available to the
higher-level code as the address of the argument, and the value of the byval
argument can be modified at the IR level.

This is necessary, but not sufficient, to fix PR20280. When PR20280 is fixed in
a follow-up commit, its test case will cover this change.

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

Revert "[Support] Promote cl::StringSaver to a separate utility"

This reverts commit r215784 / 3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa.

LLD has 3 StringSaver's, one of which takes a lock when saving the
string... Need to investigate more closely.

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

Get rid of dead code: SelectAtomic64 in X86ISelDAGtoDAG.cpp

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

[Support] Promote cl::StringSaver to a separate utility

This class is generally useful.

In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).

I've identified 2 other places in the
codebase that are open-coding this pattern:

  memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)

I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.

Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.

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

Add two helper functions: isAtLeastAcquire, isAtLeastRelease

These methods are available on AtomicOrdering values, and will be used
in a later separate patch.

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

Fix typos in comments

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

[AArch32] Add support for FP rounding operations for ARMv8/AArch32.
Phabricator Revision: http://reviews.llvm.org/D4935

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

[Option] Support MultiArg in --help

Currently, if you use a MultiArg<> option, then printing out the help/usage
message will cause an assert.  This fixes getOptionHelpName() to work with
MultiArg Options.

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

Set comdats when lazily linking functions.

We were setting the comdat when functions were copied in the initial pass, but
not when they were linked only when we found out that they are needed.

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

[FastISel][AArch64] Fix a latent bug in floating-point materialization.

The floating-point value positive zero (+0.0) is a valid immedate value
according to isFPImmLegal. As a result AArch64 FastISel went ahead and
used the immediate version of fmov to materialize the constant.

The problem is that the immediate version of fmov cannot encode an imediate for
postive zero. Instead a fmov from the zero register was supposed to be used in
this case.

This fix adds handling for this special case and uses fmov from the zero
register to materialize a positive zero (negative zeroes go to the constant
pool).

There is no test case for this, because this code is currently dead. It will be
enabled in a future commit and I will add a test case in a separate commit
after that.

This fixes <rdar://problem/18027157>.

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

Reapplying [FastISel][AArch64] Cleanup constant materialization code. NFCI.

Note: This reapplies r215582 without any modifications. The refactoring wasn't
responsible for the buildbot failures.

Original commit message:
Cleanup and prepare constant materialization code for future commits.

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

R600/SI: Move all fabs / fneg handling to patterns

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