[PATCH] Make X86-64 in the Large model always emit 64-bit calls

Make X86-64 in the Large model always emit 64-bit calls.
The large code model is documented at http://www.x86-64.org/documentation/abi.pdf and says that calls should assume their target doesn't live within the 32-bit pc-relative offset that fits in the call instruction.

To do this, we turn off the global-address->target-global-address conversion in X86TargetLowering::LowerCall(). The first attempt at this broke the lazy JIT because it can separate the movabs(imm->reg) from the actual call instruction. The lazy JIT receives the address of the movabs as a relocation and needs to record the return address from the call; and then when that call happens, it needs to patch the movabs with the newly-compiled target. We could thread the call instruction into the relocation and record the movabs<->call mapping explicitly, but  that seems to require at least as much new complication in the code generator as this change.

To fix this, we make lazy functions _always_ go through a call stub. You'd think we'd only have to force lazy calls through a stub on difficult platforms, but that turns out to break indirect calls through a function pointer. The right fix for that is to distinguish between calls and address-of operations on uncompiled functions, but that's complex enough to leave for someone else to do.

Another attempt at this defined a new CALL64i pseudo-instruction, which expanded to a 2-instruction sequence in the assembly output and was special-cased in the X86CodeEmitter's emitInstruction() function. That broke indirect calls in the same way as above.

This patch also removes a hack forcing Darwin to the small code model.  Without far-call-stubs, the small code model requires things of the JITMemoryManager that the DefaultJITMemoryManager can't provide.

Thanks to echristo for lots of testing!

[Jeffrey Yasskin, 2009-11-12 19:19:16]

Patch at http://codereview.appspot.com/download/issue154066_1033.diff

I'm unfamiliar with the code generator, so please go over that part of the
change with a fine-toothed comb.

This patch doesn't include r86941, assuming that'll be rolled back temporarily.