llvm-svn: 84725

llvm-svn: 84723

default and didn't work anyway.

llvm-svn: 84720

llvm-svn: 84713

llvm-svn: 84712

llvm-svn: 84711

llvm-svn: 84710

llvm-svn: 84709

llvm-svn: 84708

llvm-svn: 84707

llvm-svn: 84706

llvm-svn: 84705

llvm-svn: 84704

llvm-svn: 84703

llvm-svn: 84702

llvm-svn: 84701

llvm-svn: 84700

Respect src register allocation requirements when breaking anti-dependencies. Remove some dead code.

llvm-svn: 84691

s/validName/isValidName/g
s/with an Instruction/to an Instruction/g
s/RegisterMDKind/registerMDKind/g

llvm-svn: 84689

llvm-svn: 84687

transform.

llvm-svn: 84683

llvm-svn: 84682

llvm-svn: 84681

llvm-svn: 84676

fail without the patch.

llvm-svn: 84675

llvm-svn: 84674

container of the blocks and do efficient lookups. This makes
isLoopSimplifyForm much faster on large loops, fixing a significant
compile-time issue in builds with assertions enabled.

llvm-svn: 84673

llvm-svn: 84672

llvm-svn: 84671

llvm-svn: 84669

llvm-svn: 84667

llvm-svn: 84664

the estimated code size and the number of blocks when deciding whether to
do a non-trivial unswitch. This protects it from some very undesirable
worst-case behavior on large numbers of loop-unswitchable conditions, such
as in the testcase in PR5259.

llvm-svn: 84661

llvm-svn: 84658

llvm-svn: 84657

llvm-svn: 84652

JITEmitter.

I'm gradually making Functions auto-remove themselves from the JIT when they're
destroyed. In this case, the Function needs to be removed from the JITEmitter,
but the map recording which Functions need to be removed lived behind the
JITMemoryManager interface, which made things difficult.

This patch replaces the deallocateMemForFunction(Function*) method with a pair
of methods deallocateFunctionBody(void *) and deallocateExceptionTable(void *)
corresponding to the two startFoo/endFoo pairs.

llvm-svn: 84651

of the register in the instruction which kills the scavenged value.

llvm-svn: 84641

encounters an OEQ or UNE comparison, and update its callers to check
for this return status and recover. This fixes a problem resulting from
the LowerOperation hooks being called from LegalizeVectorOps, because
LegalizeVectorOps only lowers vectors, so OEQ and UNE comparisons may
still be at large. This fixes PR5092.

llvm-svn: 84640

When an incoming value for a PHI is updated, we must also updated all other
incoming values for the same BB to match, otherwise we create invalid PHIs.

llvm-svn: 84638