On Mon, 2003-11-17 at 22:44, Chris Lattner wrote:> We already have never, ever, delete this flags. "weak" and external > linkage both guarantee that. If there can be an external caller of some > function, for example, the optimizer CANNOT delete it, nor can it change > it's interface.Interesting, I wouldn't have assumed that given LLVM's support for IPO. If you find that a function is never used when doing final linking of a program, why not delete it? Just curious .. and off topic ..> > > If that was the case, I could use the full expression of LLVM assembly > > language to describe my source level information. No? > > I'm not sure exactly what you mean here, but yes, in principle, you should > be able to do exactly that. You are limited to the LLVM type system and > such, but if that is sufficient, yes.I just mean that I could define LLVM types to define the structure of my source level information. There actually isn't much that's needed. Some tables, a few bit masks, a couple structures to group things together. So, LLVM types are fine.> > > This being the case, I could emit a function in each module that returns > > the source level information. To look at it, I just JIT load the module > > and call the function. Any barriers to doing this? > > None at all!Not so fast! I have a couple issues I need your clarification on: * The source level information could reference a function (in fact, it would reference all of them!). Could this reference to the function thwart optimization? Same for global variables, types, etc. * If I wanted to create a function named "GetModuleInfo" in every module, wouldn't that cause link time symbol redefinition and the resulting errors if it was "externally visible" linkage? If I use weak linkage I avoid that problem, but then can I call the function directly after JIT loading? Isn't it "internal" to the module? (P.S. I read the entire discussion on "GCC tree linkage types" on the GCC list and got myself totally confused about what is and isn't "linkonce", etc. Had to go back to the LLVM Language Reference to straighten myself out again :) -------------- 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/20031118/1c45c073/attachment.sig>
On Mon, 17 Nov 2003, Reid Spencer wrote:> On Mon, 2003-11-17 at 22:44, Chris Lattner wrote: > > > We already have never, ever, delete this flags. "weak" and external > > linkage both guarantee that. If there can be an external caller of some > > function, for example, the optimizer CANNOT delete it, nor can it change > > it's interface. > > Interesting, I wouldn't have assumed that given LLVM's support for IPO. > If you find that a function is never used when doing final linking of a > program, why not delete it? Just curious .. and off topic ..Because it's not safe and could change the semantics of the program. What if you load a shared object that calls into the main program again: it would break. In practice the way we handle this is that we have an "internalize" pass which marks all functions except main as 'internal'. This lets the IPO machinery do all of the things you would expect to the program, including breaking it if it works like the above. If this breaks a program, the user can specify -disable-internalize on the linker command line. Alternatively, they can specify a link-map to indicate exactly which symbols should be exported. FWIW, the LLVM runtime libraries use link-maps extensively.> > > If that was the case, I could use the full expression of LLVM assembly > > > language to describe my source level information. No? > > > > I'm not sure exactly what you mean here, but yes, in principle, you should > > be able to do exactly that. You are limited to the LLVM type system and > > such, but if that is sufficient, yes. > > I just mean that I could define LLVM types to define the structure of my > source level information. There actually isn't much that's needed. Some > tables, a few bit masks, a couple structures to group things together. > So, LLVM types are fine.Yeah, ok. Makes sense.> > > This being the case, I could emit a function in each module that returns > > > the source level information. To look at it, I just JIT load the module > > > and call the function. Any barriers to doing this? > > > > None at all! > > Not so fast! I have a couple issues I need your clarification on: > > * The source level information could reference a function (in > fact, it would reference all of them!). Could this reference to > the function thwart optimization? Same for global variables, > types, etc.Yes. If you return a pointer to a function, for example, the optimizer will have to assume that something outside of the module could call it... If you represent the debug information as function bodies, also expect that the body will be optimized as well.> * If I wanted to create a function named "GetModuleInfo" in every > module, wouldn't that cause link time symbol redefinition and > the resulting errors if it was "externally visible" linkage? If > I use weak linkage I avoid that problem, but then can I call the > function directly after JIT loading? Isn't it "internal" to the > module?There is no good way to do this. The best way is to do what we do for static ctor/dtors: each ctor results in a new internal function being generated to the .bc file. Additinoally a pointer to this function is added to an array with appending linkage. The end effect is that you get "appending" semantics for functions.> (P.S. I read the entire discussion on "GCC tree linkage types" on the > GCC list and got myself totally confused about what is and isn't > "linkonce", etc. Had to go back to the LLVM Language Reference to > straighten myself out again :)Heh, I'm still trying to get the mapping of GCC types to LLVM types perfect. :) -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Mon, 2003-11-17 at 23:18, Chris Lattner wrote:> > > > * The source level information could reference a function (in > > fact, it would reference all of them!). Could this reference to > > the function thwart optimization? Same for global variables, > > types, etc. > > Yes. If you return a pointer to a function, for example, the optimizer > will have to assume that something outside of the module could call it... > If you represent the debug information as function bodies, also expect > that the body will be optimized as well.That's fine. I probably wouldn't return a pointer to function but a pointer to structure that contains the information. Getting the function that builds that structure optimized is just a bonus :)> > > * If I wanted to create a function named "GetModuleInfo" in every > > module, wouldn't that cause link time symbol redefinition and > > the resulting errors if it was "externally visible" linkage? If > > I use weak linkage I avoid that problem, but then can I call the > > function directly after JIT loading? Isn't it "internal" to the > > module? > > There is no good way to do this. The best way is to do what we do for > static ctor/dtors: each ctor results in a new internal function being > generated to the .bc file. Additinoally a pointer to this function is > added to an array with appending linkage. The end effect is that you get > "appending" semantics for functions.Yeah, I could use the same approach. A single array with appending linkage would be all I needed to access every module's information. This would work out well. Thanks for your help on this. I think I can now see clearly a way to retain my source level information directly in the byte code. -------------- 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/20031118/e8911206/attachment.sig>