If all of the inputs are zero/any_extended, create a new simple BV
which can be further optimized by other BV optimizations.

llvm-svn: 143297

llvm-svn: 143291

Should fix assertion failures on ppc buildbots.

llvm-svn: 143290

SimplifyLibCalls: Use IRBuilder.CreateGlobalString when creating a string for printf->puts, which correctly sets the unnamed_addr bit on the resulting GlobalVariable.

Fixes PR11264.

llvm-svn: 143289

llvm-svn: 143277

llvm-svn: 143268

llvm-svn: 143267

llvm-svn: 143265

llvm-svn: 143262

llvm-svn: 143247

llvm-svn: 143237

When '~imm' is encodable as a t2_so_imm but plain 'imm' is not. For example,
  mov r2, #-3
becomes
  mvn r2, #2

rdar://10349224

llvm-svn: 143235

For example,

On ARM, "mov r3, #-3" is an alias for "mvn r3, #2", so we want to use a
matcher pattern that handles the bitwise negation when mapping to t2MVNi.

llvm-svn: 143233

llvm-svn: 143231

llvm-svn: 143224

llvm-svn: 143220

llvm-svn: 143218

llvm-svn: 143217

Spotted by my super-optimizer in 186.crafty and 450.soplex.  We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.

llvm-svn: 143214

llvm-svn: 143213

For completeness - not spotted in the wild.

llvm-svn: 143211

in 186.crafty.

llvm-svn: 143209

Reapply r143202, with a manual decoding hook for SWP.  This change inadvertantly exposed a decoding ambiguity between SWP and CPS that the auto-generated decoder can't handle.

llvm-svn: 143208

fixes: Use a separate register, instead of SP, as the
calling-convention resource, to avoid spurious conflicts with
actual uses of SP. Also, fix unscheduling of calling sequences,
which can be triggered by pseudo-two-address dependencies.

llvm-svn: 143206

llvm-svn: 143203

llvm-svn: 143202

Outside an IT block, "add r3, #2" should select a 32-bit wide encoding
rather than generating an error indicating the 16-bit encoding is only
legal in an IT block (outside, the 'S' suffic is required for the 16-bit
encoding).

rdar://10348481

llvm-svn: 143201

If the register class in the source alias is a subclass of the register class
of the actual instruction, the alias can still match OK since the constraints
are strictly a subset of what the instruction can actually handle.

llvm-svn: 143200

FIXME: Would it be reproduced without target-specific operands?
FIXME: Why run llvm-mc as the same input by 3 times?
llvm-svn: 143195

Don't assume APInt::getRawData() would hold target-aware endianness nor host-compliant endianness. rawdata[0] holds most lower i64, even on big endian host.

FIXME: Add a testcase for big endian target.

FIXME: Ditto on CompileUnit::addConstantFPValue() ?
llvm-svn: 143194

llvm-svn: 143191

llvm-svn: 143190

llvm-svn: 143189

it fixes the dragonegg self-host (it looks like gcc is miscompiled).
Original commit messages:
Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.

Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.

Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.

Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.

This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.

Delete #if 0 code accidentally left in.

llvm-svn: 143188

tools that read the debug info in the .o files by making the DIE sizes more
consistent.

llvm-svn: 143186

Fixes rdar://10359193 Indvar LinearFunctionTestReplace assertion

llvm-svn: 143183

llvm-svn: 143179

on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.

Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.

Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.

Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.

This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.

llvm-svn: 143177

Previously, if invoked from a CMake build directory, 'llvm-config
--cppflags' and friends would only print a -I flag for the build
directory's header search path, because it would assume that it was
already installed, not recognising its parent directory as being the
build directory.  Teach llvm-config about CMake build directories
so that it prints a -I for both the source and build directory's
search paths.

llvm-svn: 143171

Just treat it as if the constituent D registers where specified.

rdar://10348896

llvm-svn: 143167