that it is an immediate before checking that the instruction is an
EXTRACT_SUBREG.

llvm-svn: 105585

llvm-svn: 105561

llvm-svn: 105559

rdar://7797940

llvm-svn: 105557

llvm-svn: 105556

llvm-svn: 105554

llvm-svn: 105553

llvm-svn: 105552

llvm-svn: 105551

llvm-svn: 105550

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

llvm-svn: 105534

llvm-svn: 105531

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

llvm-svn: 105519

should be calling it.

llvm-svn: 105517

unless using -arm-tail-calls.

llvm-svn: 105515

llvm-svn: 105514

llvm-svn: 105513

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: 105508

Radar 8055687.

llvm-svn: 105505

llvm-svn: 105502

register pressure.

llvm-svn: 105501

llvm-svn: 105498

llvm-svn: 105496

llvm-svn: 105495

llvm-svn: 105492