llvm-svn: 105554

llvm-svn: 105551

determinstic. Instead, give SCEV objects an arbitrary sequence
number.

llvm-svn: 105548

that the operands are sorted.

llvm-svn: 105546

the operands.

llvm-svn: 105545

llvm-svn: 105544

llvm-svn: 105542

llvm-svn: 105541

scrounging through SCEVUnknown contents and SCEVNAryExpr operands;
instead just do a simple deterministic comparison of the precomputed
hash data.

Also, since this is more precise, it eliminates the need for the slow
N^2 duplicate detection code.

llvm-svn: 105540

encapsulation to force the users of these classes to know about the internal
data structure of the Operands structure. It also can lead to errors, like in
the MSIL writer.

llvm-svn: 105539

Partial specialization was not checking the callsite to make sure it was using the same constants as the specialization, leading to calls to the wrong specialization.  Patch by Takumi Nakamura\!

llvm-svn: 105528

llvm-svn: 105527

In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type

llvm-svn: 105524

yet, only assembly encoding support.

llvm-svn: 105521

unless using -arm-tail-calls.

llvm-svn: 105515

llvm-svn: 105514

llvm-svn: 105511

there could be multiple subexpressions within a single expansion which
require insert point adjustment. This fixes PR7306.

llvm-svn: 105510

I don't think this ever resulted in problems on x86, but it
would on ARM.

llvm-svn: 105509

llvm-svn: 105502

register pressure.

llvm-svn: 105501

llvm-svn: 105498

llvm-svn: 105492

Copy location info for current function argument from dbg.declare if respective store instruction does not have any location info.

llvm-svn: 105490

llvm-svn: 105481

llvm-svn: 105480

register allocation.

Process all of the clobber lists at the end of the function, marking the
registers as used in MachineRegisterInfo.

This is necessary in case the calls clobber callee-saved registers (sic).

llvm-svn: 105473

8060143, although this doesn't fix the real problem with tail call.

llvm-svn: 105472

llvm-svn: 105470

llvm-svn: 105454

replace an OpA with a widened OpB, it is possible to get new uses of OpA due to CSE
when recursively updating nodes.  Since OpA has been processed, the new uses are
not examined again.  The patch checks if this occurred and it it did, updates the
new uses of OpA to use OpB.

llvm-svn: 105453

llvm-svn: 105441

VECTOR_SHUFFLEs to REG_SEQUENCE instructions.  The standard ISD::BUILD_VECTOR
node corresponds closely to REG_SEQUENCE but I couldn't use it here because
its operands do not get legalized.  That is pretty awful, but I guess it
makes sense for other targets.  Instead, I have added an ARM-specific version
of BUILD_VECTOR that will have its operands properly legalized.
This fixes the rest of Radar 7872877.

llvm-svn: 105439

Check that all the instructions are in the same basic block, that the
EXTRACT_SUBREGs write to the same subregs that are being extracted, and that
the source and destination registers are in the same regclass.  Some of
these constraints can be relaxed with a bit more work.  Jakob suggested
that the loop that checks for subregs when NewSubIdx != 0 should use the
"nodbg" iterator, so I made that change here, too.

llvm-svn: 105437

llvm-svn: 105435

llvm-svn: 105427

A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.

llvm-svn: 105413

needs to demand the high bits because it's asserting that they're zero.

llvm-svn: 105406

llvm-svn: 105399

registers it defines then interfere with an existing preg live range.

For instance, if we had something like these machine instructions:

BB#0
  ... = imul ... EFLAGS<imp-def,dead>
  test ..., EFLAGS<imp-def>
  jcc BB#2 EFLAGS<imp-use>

BB#1
  ... ; fallthrough to BB#2

BB#2
  ... ; No code that defines EFLAGS
  jcc ... EFLAGS<imp-use>

Machine sink will come along, see that imul implicitly defines EFLAGS, but
because it's "dead", it assumes that it can move imul into BB#2. But when it
does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and
messes up the condition code for the jump (and pretty much anything else which
relies upon it being correct).

The solution is to know which pregs are live going into a basic block. However,
that information isn't calculated at this point. Nor does the LiveVariables pass
take into account non-allocatable physical registers. In lieu of this, we do a
*very* conservative pass through the basic block to determine if a preg is live
coming out of it.

llvm-svn: 105387