Skip to content
  1. Nov 18, 2009
  2. Nov 16, 2009
    • Jeffrey Yasskin's avatar
      Make X86-64 in the Large model always emit 64-bit calls. · 10d3604a
      Jeffrey Yasskin authored
      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!
      
      llvm-svn: 88984
      10d3604a
  3. Nov 15, 2009
  4. Nov 14, 2009
  5. Nov 11, 2009
  6. Nov 10, 2009
  7. Nov 08, 2009
  8. Nov 06, 2009
  9. Nov 05, 2009
  10. Nov 04, 2009
  11. Nov 03, 2009
  12. Nov 02, 2009
  13. Oct 31, 2009
  14. Oct 30, 2009
  15. Oct 29, 2009
Loading