[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol

[Chris Lattner]

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/