Displaying 5 results from an estimated 5 matches for "functions_end".
Did you mean:
functionend
2004 Jun 19
2
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
...global variables, and ::begin/end
> iterate over the functions, some of which may be prototypes.
This confused Vladimir and I remember it confusing me when I was
reviewing LLVM core a few months ago. Would it be worthwhile to consider
naming these globals_begin/globals_end and
functions_begin/functions_end? so their use is completely clear?
Reid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2004...
2004 Jun 19
0
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
...in/end
> > iterate over the functions, some of which may be prototypes.
>
> This confused Vladimir and I remember it confusing me when I was
> reviewing LLVM core a few months ago. Would it be worthwhile to consider
> naming these globals_begin/globals_end and
> functions_begin/functions_end? so their use is completely clear?
Sure, they can be renamed. For commonly used methods like this I would
like to keep them relatively terse though. How about gvbegin/end and
funcbegin/end? Would anyone like to make a patch? :)
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre...
2004 Jun 19
1
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
...over the functions, some of which may be prototypes.
> >
> > This confused Vladimir and I remember it confusing me when I was
> > reviewing LLVM core a few months ago. Would it be worthwhile to consider
> > naming these globals_begin/globals_end and
> > functions_begin/functions_end? so their use is completely clear?
>
> Sure, they can be renamed. For commonly used methods like this I would
> like to keep them relatively terse though. How about gvbegin/end and
> funcbegin/end? Would anyone like to make a patch? :)
>
> -Chris
-------------- next part ---...
2004 Jun 18
0
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
On Fri, 18 Jun 2004, Vladimir Prus wrote:
> > 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
2004 Jun 18
3
[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.