Chris,
I've done a little more thinking about this (putting source definitions
into bytecode/assembler) files. Despite my previous assertions to the
contrary, using the LLVM type and constant global declarations in the
source definitions section is a little limiting because (a) it limits
the choices for source compiler writers, (b) it might imply a larger
amount of information than would otherwise be possible, and (c) it
implies a contract between LLVM and source compiler writers that LLVM
shouldn't have to support.
So, here's what I suggest:
1. LLVM supports a named section that contains a BLOB. LLVM doesn't
care about the contents of the BLOB but will assist in its
maintenance (see below). To LLVM its a name and a chunk of data.
2. The name of the section is to allow information from different
compilers to be distinguished.
3. LLVM provides a C++ class that represents the named blob. I'll
call this class "ExtraInfo".
4. Source compiler writers can subclass ExtraInfo to their heart's
content.
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.
6. During compilation, any ExtraInfo subclasses created by the
source compiler are attached to the Module object and the
maintenance provided in 5 is invoked automatically as
optimizations occur.
Does this sound reasonable?
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/7b51d682/attachment.sig>
> I've done a little more thinking about this (putting source definitions > into bytecode/assembler) files. Despite my previous assertions to the > contrary, using the LLVM type and constant global declarations in the > source definitions section is a little limiting because (a) it limits > the choices for source compiler writers, (b) it might imply a larger > amount of information than would otherwise be possible, and (c) it > implies a contract between LLVM and source compiler writers that LLVM > shouldn't have to support.Again, reiterating from my more complete response in the previous mail, I'm still thinking it is "too early" to support this. :)> So, here's what I suggest: > > 1. LLVM supports a named section that contains a BLOB. LLVM doesn't > care about the contents of the BLOB but will assist in its > maintenance (see below). To LLVM its a name and a chunk of data. > 2. The name of the section is to allow information from different > compilers to be distinguished. > 3. LLVM provides a C++ class that represents the named blob. I'll > call this class "ExtraInfo". > 4. Source compiler writers can subclass ExtraInfo to their heart's > content. > 6. During compilation, any ExtraInfo subclasses created by the > source compiler are attached to the Module object and the > maintenance provided in 5 is invoked automatically as > optimizations occur.All of this is trivially implementable...> 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? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
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>