Move the compact encoding from the target-specific library to the code-gen
library.

llvm-svn: 135443

Sink getDwarfRegNum, getLLVMRegNum, getSEHRegNum from TargetRegisterInfo down
to MCRegisterInfo. Also initialize the mapping at construction time.

This patch eliminate TargetRegisterInfo from Target

Sink getDwarfRegNum, getLLVMRegNum, getSEHRegNum from TargetRegisterInfo down
to MCRegisterInfo. Also initialize the mapping at construction time.

This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.

llvm-svn: 135424

show more ...

Fixed version of 121434 with no new memory leaks.

llvm-svn: 121471

Revert my previous patch to make the valgrind bots happy.

llvm-svn: 121461

Initial support for the cfi directives. This is just enough to get

f:
.cfi_startproc
nop
.cfi_endproc

assembled (on ELF).

llvm-svn: 121434

CodeGen-Windows: Only emit _fltused if a VarArg function is called with floating point args.
This should be the minimum set of functions that could possibly need it.

llvm-svn: 116978

Get rid of static constructors for pass registration. Instead, every pass exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency

Get rid of static constructors for pass registration. Instead, every pass exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.

Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.

I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.

llvm-svn: 116820

show more ...

X86-Windows: Emit an undefined global __fltused symbol when targeting Windows
if any floating point arguments are passed to an external function.

llvm-svn: 116665

Whitespace!

llvm-svn: 116664

Now with fewer extraneous semicolons!

llvm-svn: 115996

zap dead code.

llvm-svn: 113073

Reapply r110396, with fixes to appease the Linux buildbot gods.

llvm-svn: 110460

Revert r110396 to fix buildbots.

llvm-svn: 110410

Don't use PassInfo* as a type identifier for passes. Instead, use the address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.

llvm-svn: 110396

Fix batch of converting RegisterPass<> to INTIALIZE_PASS().

llvm-svn: 109045

Revert r108369, sorting llvm.dbg.declare information by source position,
since it doesn't work for front-ends which don't emit column information
(which includes llvm-gcc in its present configuration

Revert r108369, sorting llvm.dbg.declare information by source position,
since it doesn't work for front-ends which don't emit column information
(which includes llvm-gcc in its present configuration), and doesn't
work for clang for K&R style variables where the variables are declared
in a different order from the parameter list.

Instead, make a separate pass through the instructions to collect the
llvm.dbg.declare instructions in order. This ensures that the debug
information for variables is emitted in this order.

llvm-svn: 108538

show more ...

Make the order in which variables are described in debug information
independent of the order that isel happens to visit the dbg_declare
intrinsics. This fixes a bug in which the formal arguments wer

Make the order in which variables are described in debug information
independent of the order that isel happens to visit the dbg_declare
intrinsics. This fixes a bug in which the formal arguments were
being printed in reverse order, now that fast isel is going bottom up.

llvm-svn: 108369

show more ...

The JIT calls TidyLandingPads to tidy up the landing pads. However, because the
JIT doesn't use the MC back-end asm printer to emit labels that it uses, the
section for the MCSymbol is never set. And

The JIT calls TidyLandingPads to tidy up the landing pads. However, because the
JIT doesn't use the MC back-end asm printer to emit labels that it uses, the
section for the MCSymbol is never set. And thus the MCSymbol for the EH label
isn't marked as "defined". Because of that, TidyLandingPads removes the needed
landing pads from the JIT output. This breaks EH for every JIT program.

This is a work-around for this limitation. We pass in the label locations
map. If the label has a non-zero value, then it was "emitted" by the JIT and
TidyLandingPads shouldn't remove that label.

A nicer solution would be to mark the MCSymbol as "used" by the JIT and not rely
upon the section being set to determine if it's defined or not.

llvm-svn: 101453

show more ...

prune includes

llvm-svn: 101385

Add const qualifiers to CodeGen's use of LLVM IR constructs.

llvm-svn: 101334

Give MachineModuleInfo an actual Module*.

llvm-svn: 100508

Fix PR6673: updating the callback should not clear the map.

llvm-svn: 99227

Fix the third (and last known) case of code update problems due
to LLVM IR changes with addr label weirdness. In the testcase, we
generate references to the two bb's when codegen'ing the first
func

Fix the third (and last known) case of code update problems due
to LLVM IR changes with addr label weirdness. In the testcase, we
generate references to the two bb's when codegen'ing the first
function:

_test1: ## @test1
leaq Ltmp0(%rip), %rax
..
leaq Ltmp1(%rip), %rax

Then continue to codegen the second function where the blocks
get merged. We're now smart enough to emit both labels, producing
this code:

_test_fun: ## @test_fun
## BB#0: ## %entry
Ltmp1: ## Block address taken
Ltmp0:
## BB#1: ## %ret
movl $-1, %eax
ret

Rejoice.

llvm-svn: 98595

show more ...

Implement support for the case when a reference to a addr-of-bb
label is generated, but then the block is deleted. Since the
value is undefined, we just emit the label right after the entry
label

Implement support for the case when a reference to a addr-of-bb
label is generated, but then the block is deleted. Since the
value is undefined, we just emit the label right after the entry
label of the function. It might matter that the label is in the
same section as the function was afterall.

llvm-svn: 98579

show more ...

Fix the case when a reference to an address taken BB is emitted in one
function, then the BB is RAUW'd before the definition is emitted. There
are still two cases not being handled, but this should

Fix the case when a reference to an address taken BB is emitted in one
function, then the BB is RAUW'd before the definition is emitted. There
are still two cases not being handled, but this should improve us back to
the situation before I touched anything.

llvm-svn: 98566

show more ...