R600/SI: Refactor fneg / fabs patterns

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215746 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Use source modifier for f64 fabs

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215747 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Use source modifiers for f64 fneg

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215748 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
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
[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
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
[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
[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
Fix typos in comments

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215777 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
[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
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
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
[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
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] 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
[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
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
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