Not sure why we weren't catching this with -Wunused-parameter...

Spotted by inspection.

llvm-svn: 184271

llvm-svn: 184269

llvm-svn: 184268

llvm-svn: 184267

llvm-svn: 184263

llvm-svn: 184261

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.

llvm-svn: 184260

llvm-svn: 184258

Currently, we only output the name.

llvm-svn: 184255

The information was correct pre-LPAE.

llvm-svn: 184253

llvm-svn: 184247

rdar://14194152

llvm-svn: 184244

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

llvm-svn: 184242

llvm-svn: 184239

llvm-svn: 184236

llvm-svn: 184235

llvm-svn: 184233

[ARMTargetLowering] ARMISD::{SUB,ADD}{C,E} second result is a boolean implying that upper bits are always 0.

llvm-svn: 184231

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.

llvm-svn: 184230

llvm-svn: 184229

llvm-svn: 184228

"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

llvm-svn: 184224

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.

llvm-svn: 184222

When producing objects that are abi compliant we are 
marking neither the object file nor the assembly file
correctly and thus generate warnings. 

We need to set the EF_CPIC flag in the ELF header when
generating direct object.

Note that the warning is only generated when compiling without PIC.

When compiling with clang the warning will be suppressed by supplying:

 -Wa,-mno-shared -Wa,-call_nonpic

Also the following directive should also be added:

	.option	pic0

when compiling without PIC,  This eliminates the need for supplying:

  -mno-shared -call_nonpic

on the assembler command line.

Patch by Douglas Gilmore

llvm-svn: 184220

llvm-svn: 184219

llvm-svn: 184217

llvm-svn: 184213

llvm-svn: 184210

For decoding, keep the current behavior of always decoding these as their REP
versions. In the future, this could be improved to recognize the cases where
these behave as XACQUIRE and XRELEASE and decode them as such.

llvm-svn: 184207

llvm-svn: 184206

llvm-svn: 184204

llvm-svn: 184203

llvm-svn: 184202

llvm-svn: 184201

llvm-svn: 184200

llvm-svn: 184198

llvm-svn: 184196

llvm-svn: 184193

llvm-svn: 184191

This allows the compiler to see the enum and warn about it. While in here,
fix a switch to not use a default and fix style violations.

llvm-svn: 184186