Teach isKnownNonNull that a nonnull return is not null. Add a test for this case as well as the case of a nonnull attribute (already handled but not tested).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209193 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-readobj: use range-based for loop

Convert an additional site to a range based for loop.  NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209194 91177308-0d34-0410-b5e6-96231b3b80d8
[LV][REFACTOR] One more tiny fix for printing debug locations in loop vectorizer. Now consistent with the remarks emitter.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209197 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Tune LEA usage for Silvermont

According to Intel Software Optimization Manual on Silvermont in some cases LEA
is better to be replaced with ADD instructions:
"The rule of thumb for ADDs and LEAs is that it is justified to use LEA
with a valid index and/or displacement for non-destructive destination purposes
(especially useful for stack offset cases), or to use a SCALE.
Otherwise, ADD(s) are preferable."

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209198 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen: convert InstAlias's Emit bit to an int.

When multiple aliases overlap, the correct string to print can often be
determined purely by considering the InstAlias declarations in some particular
order. This allows the user to specify that order manually when desired,
without resorting to hacking around with the default lexicographical order on
Record instantiation, which is error-prone and ugly.

I was also mistaken about "add w2, w3, w4" being the same as "add w2, w3, w4,
uxtw". That's only true if Rn is the stack pointer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209199 91177308-0d34-0410-b5e6-96231b3b80d8
ARMEB: Additional test files for ARM fixups

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209200 91177308-0d34-0410-b5e6-96231b3b80d8
[Mips] Add more relocation types and MIPS specific e_flags constants.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209201 91177308-0d34-0410-b5e6-96231b3b80d8
Legalizer: Make bswap promotion safe for vectors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209202 91177308-0d34-0410-b5e6-96231b3b80d8
Add parentheses to suppress the gcc warning '-Wparentheses'.

No functional changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209203 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen: permit non-leaf ComplexPattern uses

This allows the results of a ComplexPattern check to be distributed to separate
named Operands, instead of the current system where all results must apply (and
match perfectly) with a single Operand.

For example, if "some_addrmode" is a ComplexPattern producing two results, you
can write:

   def : Pat<(load (some_addrmode GPR64:$base, imm:$offset)),
             (INST GPR64:$base, imm:$offset)>;

This should allow neater instruction definitions in TableGen that don't put all
possible aspects of addressing into a single operand, but are still usable with
relatively simple C++ CodeGen idioms.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209206 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM64] Port basic-a64-diagnostics.s over to ARM64

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209207 91177308-0d34-0410-b5e6-96231b3b80d8
Temporarily revert: r209129 - [mips][mips64r6] Sorted *_ENC, *_DESC classes and tests

After discussion with Zoran, we have decided to temporarily revert this commit.
It's causing some difficult to resolve conflicts and we are under time pressure
to deliver an initial MIPS64r6 compiler.

We will re-apply an equivalent patch once the time pressure has passed.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209211 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up language and grammar.

Based on a patch by jfcaron3@gmail.com!
PR19806

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209216 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] PR19796: Also match ISD::TargetConstant in isIntS16Immediate

The SplitIndexingFromLoad changes exposed a latent isel bug in the PowerPC64
backend.  We matched an immediate offset with STWX8 even though it only
supports register offset.

The culprit is the complex-pattern predicate, SelectAddrIdx, which decides
that if the offset is not ISD::Constant it must be a register.

Many thanks to Bill Schmidt for testing this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209219 91177308-0d34-0410-b5e6-96231b3b80d8
Avoids DCE on write_register

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209222 91177308-0d34-0410-b5e6-96231b3b80d8
PR19767: DebugInfo emission of pointer constants.

In refactoring DwarfUnit::isUnsignedDIType I restricted it to only work
on values with signedness (unsigned or signed), asserting on anything
else (which did uncover some bugs). But it turns out that we do need to
emit constants of signless data, such as pointer constants - only null
pointer constants are known to need this so far, but it's conceivable
that there might be non-null pointer constants at some point (hardcoded
address offsets for device drivers?).

This patch just uses 'unsigned' for signless data such as pointer
constants. Arguably we could use signless representations
(DW_FORM_dataN) instead, allowing a trinary result from isUnsignedDIType
(signed, unsigned, signless), but this seems reasonable for now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209223 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite calculateDbgValueHistory to make it (hopefully) more transparent.

This change preserves the original algorithm of generating history
for user variables, but makes it more clear.

High-level description of algorithm:
Scan all the machine basic blocks and machine instructions in the order
they are emitted to the object file. Do the following:
1) If we see a DBG_VALUE instruction, add it to the history of the
corresponding user variable. Keep track of all user variables, whose
locations are described by a register.
2) If we see a regular instruction, look at all the registers it clobbers,
and terminate the location range for all variables described by these registers.
3) At the end of the basic block, terminate location ranges for all
user variables described by some register.

Although this change shouldn't be user-visible (the contents of .debug_loc section
should be the same), it changes some internal assumptions about the set
of instructions used to track the variable locations. Watching the bots.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209225 91177308-0d34-0410-b5e6-96231b3b80d8
Fix test breakage introduced in r209223.

Oops, broke the broken enum constants again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209226 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalValue: Automatically reset visibility when setting local linkage

r208264 started asserting in `setLinkage()` and `setVisibility()` that
visibility and linkage are compatible.  There are a few places in clang
where visibility is set first, and then linkage later, so the assert
fires.  In `setLinkage()`, it's clear what the visibility *should* be,
so rather than updating all the call sites just automatically fix the
visibility.

The testcase for this is for *clang*, so it'll follow separately in cfe.

PR19760

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209227 91177308-0d34-0410-b5e6-96231b3b80d8
[LSR] Canonicalize reg1 + ... + regN into reg1 + ... + 1*regN.

This commit introduces a canonical representation for the formulae.
Basically, as soon as a formula has more that one base register, the scaled
register field is used for one of them. The register put into the scaled
register is preferably a loop variant.
The commit refactors how the formulae are built in order to produce such
representation.
This yields a more accurate, but still perfectible, cost model.

<rdar://problem/16731508>


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