[LLVMdev] Documentation on llvm::CodeModel?

[Yuri]

Where is the documentation on what llvm::CodeModel values mean?
I observe that with Small code model, elf relocation entries become 32
bit, and the corresponding functions are expected to be in the same
32-bit memory segment.
But is it possible to make specific call instances still treated as far
calls?
What is the difference between those values in general?

Googling for llvm CodeModel terms only brings this:
http://llvm.org/docs/doxygen/html/namespacellvm_1_1CodeModel.html Blank
doxygen "documentation".

Something should be written up on what those values are for, what is the
difference between them, etc.

Yuri
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Anton Korobeynikov]

They are defined in section 3.5.1 of X86-64 platform ABI:
http://www.x86-64.org/documentation/abi.pdf

Googling for "code mode x86-64" also brings bunch of interesting topic
including:

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/x86_64_code.html
http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models/

Hope this helps

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Tim Northover]

Hi Yuri,

On 20 February 2014 00:02, Yuri <yu...@rawbw.com> wrote:
> Where is the documentation on what llvm::CodeModel values mean?

It's mostly in the platform ABI documents since each architecture has
different thresholds where the benefits appear, depending on what
instructions are available. LLVM just exposes an enum of the common
ones, interpreted by each backend as it wants.

> But is it possible to make specific call instances still treated as far
> calls?

Not really. The historical solution to that problem was separating
"near" and "far" pointers, I think, which LLVM doesn't support as far
as I know. It might be implementable in terms of addressspaces in
LLVM, though the targets don't at the moment.

Other than that, compiling PIC and getting a GOT entry might work,
depending on what your situation is.

Cheers.

Tim.