[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol

[Vladimir Prus]

Chris Lattner wrote:

> > Second, MO_ExternalSymbol is used for storing name of external
> > variable/function, right? Why it's not possible to use MO_GlobalAddress,
> > where returned GlobalValue* has isExternal set to true? The
> > GlobalValue::getName would return the name of the symbol.
>
> Using the GlobalValue is certainly the preferred way if you have it.
> MO_ExternalSymbol should only be used for functions that might not
> actually exist in the LLVM module for the function.  In particular, this
> would include any functions in a code-generator specific runtime library
> and malloc/free.  The X86 code generator compiles floating point modulus
> into fmod calls, and 64-bit integer div/rem into runtime library calls.

And why isn't it possible to just make those functions known to LLVM? After 
all, *I think*, if this function is to be called, it should be declared in 
assembler, and so you have to pass some information abou those function to 
the code printer. (Of course, it's possible to just directly print the 
declarations, but that's scary).

There's another issue I don't understand. The module consists of functions and 
constants. I'd expect that external function declarations are also constants, 
with appropriate type. However, it seems they are not included in 
[Module::gbegin(), Module::gend()], insteads, they a Function objects with 
isExternal set to true. 

To me this seems a bit confusing -- it would be clearer if there we plain 
functions with bodies and everything else were GlobalValue.

Anyther question is about SymbolTable. Is it true that it's a mapping from 
name to objects in Module, and than all objects accessible via SymbolsTable 
are either in the list of functions or in the list of global values?

> If you have a GlobalValue*, please do use it, but if it's one of these
> cases where the called function might not exist in the LLVM view of the
> world, then use an ExternalSymbol.

OK.

Thanks,
Volodya