On Mon, 2003-11-17 at 21:42, Chris Lattner wrote:> > > 5. The ExtraInfo class supports pure virtual methods that are > > invoked by LLVM to notify its subclass(es) when an optimization > > causes a function, type or global variable to be deleted. No > > other notifications should be necessary. > > This sounds _extremely_ limited. What if the optimizer deletes arguments > to functions? Presumably your information will have to be updated, right? > What if it specializes the function because every caller has some > property? > > -ChrisYeah, you're right. I thought about it some more after I posted and it boils down to ExtraInfo actually needing to be notified about EVERY change. Not fun. I've managed to get myself completely confused on this subject, but have just shed some "old think" from previous compilers. The "old think" is that the source level symbol stuff must be completely segregated from the program itself (e.g. ELF debug sections). But why? Why shouldn't the source level information be coded right into the bytecode as part of the program? Why shouldn't it undergo optimization? The only thing that I would need is a some kind of linkage class or flag that says "never, ever delete this". If that was the case, I could use the full expression of LLVM assembly language to describe my source level information. No? 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? 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/20031117/45d676cc/attachment.sig>
> Yeah, you're right. I thought about it some more after I posted and it > boils down to ExtraInfo actually needing to be notified about EVERY > change. Not fun.Yup.> I've managed to get myself completely confused on this subject, but have > just shed some "old think" from previous compilers. The "old think" is > that the source level symbol stuff must be completely segregated from > the program itself (e.g. ELF debug sections).Heh, LLVM requires a little bit of that. :)> But why? Why shouldn't the source level information be coded right into > the bytecode as part of the program? Why shouldn't it undergo > optimization? The only thing that I would need is a some kind of > linkage class or flag that says "never, ever delete this".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.> 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.> 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! -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
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>