llvm dev - Jun 2004 - [LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol

Hi,
here I am again with "why is this so" kind of a question. Among
different
types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress.

For MO_GlobalAddress, we can get usefull information from the getGlobal() 
method, which returns GlobalValue*. Wouldn'it it be better is 
MO_GlobalAddress be called MO_GlobalValue, for consistency?

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.

- Volodya

On Thu, 17 Jun 2004, Vladimir Prus wrote:
>
> Hi,
> here I am again with "why is this so" kind of a question. Among
different
> types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress.
>
> For MO_GlobalAddress, we can get usefull information from the getGlobal()
> method, which returns GlobalValue*. Wouldn'it it be better is
> MO_GlobalAddress be called MO_GlobalValue, for consistency?
I think that it could be reasonable to make this change, but it is also
reasonable to keep it named MO_GlobalAddress (the operand is the *address*
of the global not it's *value*).

The MachineInstr/Operand classes are a fertile source of warts like this,
which we are continually refactoring into a simpler interface.  In this
particular case I don't think it's super important to make the change.
> 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.

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.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

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