Vladimir Prus
2004-Jun-17 08:12 UTC
[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
Chris Lattner
2004-Jun-17 12:12 UTC
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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/
Vladimir Prus
2004-Jun-18 09:19 UTC
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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
Possibly Parallel Threads
- [LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
- [LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
- [LLVMdev] MachineOperand type
- [LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
- [LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol