During SelectionDAG building explicitly set a node to constant zero when the
value is zero.
This allows optmizations to kick in more easily.
Fix some test cases so that they remain meaningful (i.e., not completely dead
coded) when optimizations apply.

<rdar://problem/14096009> superfluous multiply by high part of zero-extended
value.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184222 91177308-0d34-0410-b5e6-96231b3b80d8
Change the arm assembler to support this from the v7c spec:
"When assembling to the ARM instruction set, the .N qualifier produces
an assembler error and the .W qualifier has no effect."

In the pre-matcher handler in the asm parser the ".w" (wide) qualifier 
when in ARM mode is now discarded. And an error message is now
produced when the ".n" (narrow) qualifier is used in ARM mode.

Test cases for these were added.

rdar://14064574


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184224 91177308-0d34-0410-b5e6-96231b3b80d8
Fix 80 col violation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184228 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unused Path::canRead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184229 91177308-0d34-0410-b5e6-96231b3b80d8
Converted an overly aggressive assert to a conditional check in AddCombineTo64bitMLAL.

Said assert assumes that ADDC will always have a glue node as its second
argument and is checked before we even know that we are actually performing the
relevant MLAL optimization. This is incorrect since on ARM we *CAN* codegen ADDC
with a use list based second argument. Thus to have both effects, I converted
the assert to a conditional check which if it fails we do not perform the
optimization.

In terms of tests I can not produce an ADDC from the IR level until I get in my
multiprecision optimization patch which is forthcoming. The tests for said patch
would cause this assert to fail implying that said tests will provide the
relevant tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184230 91177308-0d34-0410-b5e6-96231b3b80d8
[ARMTargetLowering] ARMISD::{SUB,ADD}{C,E} second result is a boolean implying that upper bits are always 0.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184231 91177308-0d34-0410-b5e6-96231b3b80d8
Add a can_write function to PathV2.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184235 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: remove accidental test output file.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184236 91177308-0d34-0410-b5e6-96231b3b80d8
We want a string representation of the attribute, not the kind as a string.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184239 91177308-0d34-0410-b5e6-96231b3b80d8
[yaml2obj][ELF] Add dummy .strtab section.

This will be needed later for holding symbol names, due to the libObject
issue mentioned in the commit message of r184161.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184242 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: Add optional datatype suffix to NEON mvn asm syntax.

rdar://14194152

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184244 91177308-0d34-0410-b5e6-96231b3b80d8
Identify me on IRC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184247 91177308-0d34-0410-b5e6-96231b3b80d8
Small correction to unordered memory code generation of ARM LDRD

The information was correct pre-LPAE.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184253 91177308-0d34-0410-b5e6-96231b3b80d8
[yaml2obj][ELF] Rudimentary symbol table support.

Currently, we only output the name.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184255 91177308-0d34-0410-b5e6-96231b3b80d8
[yaml2obj][ELF] Ensure STN_UNDEF entry is present.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184258 91177308-0d34-0410-b5e6-96231b3b80d8
[yaml2obj][ELF] Don't monkeypatch the YAML sections.

Previously, we would monkeypatch the vector of YAML::Section's in order
to ensure that the SHT_NULL entry is present. Now we just add it
unconditionally.

The proliferation of small numerical adjustments is beginning to
frighten me, but I can't think of a way having a single point of truth
for them without introducing a whole new layer  of data structures (i.e.
lots of code and complexity) between the YAML and binary ELF formats.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184260 91177308-0d34-0410-b5e6-96231b3b80d8
Use GetUnderlyingObject instead of custom function

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184261 91177308-0d34-0410-b5e6-96231b3b80d8
[yaml2obj][ELF] Support st_info through `Binding` and `Type` YAML keys.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184263 91177308-0d34-0410-b5e6-96231b3b80d8
There is no ELF ABI version enum.

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