On Wed, 26 Apr 2006, Archie Cobbs wrote:>>> With no annotation support, it doesn't seem like you can. This is >>> the problem. I'm not saying annotations are good, just that they >>> represent one (sub-optimal) solution to the problem. Without them, >>> we have zero solutions to the problem. >> >> Why do you believe this? > > Sorry, that sounded more pessimistic that it was supposed to. > > What I meant was, there are probably better solutions out there, > but they haven't been implemented yet and it will take some work > (both defining them and coding them) to get there. At least, that's > what I think I've heard so far (don't forget I'm the "newbie" here :-)I still don't follow. Having annotations on the IR is *exactly* equivalant to having a map from IR objects to the things you want to annotate them with. Why isn't this just as acceptable (and problematic) as annotations? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:> On Wed, 26 Apr 2006, Archie Cobbs wrote: >>>> With no annotation support, it doesn't seem like you can. This is >>>> the problem. I'm not saying annotations are good, just that they >>>> represent one (sub-optimal) solution to the problem. Without them, >>>> we have zero solutions to the problem. >>> >>> Why do you believe this? >> >> Sorry, that sounded more pessimistic that it was supposed to. >> >> What I meant was, there are probably better solutions out there, >> but they haven't been implemented yet and it will take some work >> (both defining them and coding them) to get there. At least, that's >> what I think I've heard so far (don't forget I'm the "newbie" here :-) > > I still don't follow. Having annotations on the IR is *exactly* > equivalant to having a map from IR objects to the things you want to > annotate them with. > > Why isn't this just as acceptable (and problematic) as annotations?Perhaps it is. In which case, I guess we need something better or else we'll never be able to do certain optimizations. Or, if something better doesn't exist, then we'll have to figure out how to eliminate or workaround the problems that annotations have. I.e., maybe annotations are bringing up exactly the right issues, and by discarding them we're just shooting the messenger... For example (I'm making this up, you may have already considered and rejected it): you could have a callback function (supplied by the front end) that would be invoked any time an optimization pass needed to {add, delete, move, modify} an LLVM instruction. In other words, all the questions about "what to do with the annotation in situation X" you simply delegate to the front end to deal with. So then you no longer have to worry about what happens to the annotations during a transformation. OK I'll shut up now and go read about annotation in the archives... :-) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes:Archie> Perhaps it is. In which case, I guess we need something better or else Archie> we'll never be able to do certain optimizations. I'm curious to know which optimizations you have in mind. Tom
On Wed, 2006-04-26 at 16:32 -0500, Chris Lattner wrote:> I still don't follow. Having annotations on the IR is *exactly* > equivalant to having a map from IR objects to the things you want to > annotate them with. > > Why isn't this just as acceptable (and problematic) as annotations?Because LLVM doesn't store that map, someone else has to. Furthermore, LLVM doesn't assist with the on-disk association. The pointers in the map are useless after the IR objects are written to disk and the program terminates. LLVM also doesn't have a facility for reconstruction of the map when bytecode is read. We've talked about this before and loosely suggested that it might be possible to: 1. have llvm provide an interface for storing a "blob" at the end of a bytecode file. LLVM ignores this blob. 2. Augment BytecodeHandler.h to allow for unique identifiers with each object being read (it does some of this now). 3. Create something like BytecodeHandler for writing so that the unique identifiers can be associated with the user's map. 4. Leave details of the "blob" construction up to the user. If there's a better solution, I'm all ears. 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/20060426/daaea2f2/attachment.sig>
On Wed, 26 Apr 2006, Reid Spencer wrote:> On Wed, 2006-04-26 at 16:32 -0500, Chris Lattner wrote: >> I still don't follow. Having annotations on the IR is *exactly* >> equivalant to having a map from IR objects to the things you want to >> annotate them with. >> >> Why isn't this just as acceptable (and problematic) as annotations? > > Because LLVM doesn't store that map, someone else has to.*shrug*> Furthermore, LLVM doesn't assist with the on-disk association. The > pointers in the map are useless after the IR objects are written to disk > and the program terminates. LLVM also doesn't have a facility for > reconstruction of the map when bytecode is read.LLVM has a symbol table that is persistent across serialization. Ensure that the annotated objects have a name, and you can find them.> We've talked about this before and loosely suggested that it might be > possible to: > 1. have llvm provide an interface for storing a "blob" at the end > of a bytecode file. LLVM ignores this blob.You don't need an llvm interface for this, you can embed the LLVM .bc file into other bigger tcontainers.> 2. Augment BytecodeHandler.h to allow for unique identifiers with > each object being read (it does some of this now). > 3. Create something like BytecodeHandler for writing so that the > unique identifiers can be associated with the user's map. > 4. Leave details of the "blob" construction up to the user.I don't understand this, but I also don't see why it is necessary. Using the symbol table should be perfectly acceptable. Echoing Tom's sentiment: without a specific problem we're trying to solve, coming up with complex overgeneral solutions is not a useful way to spend time. I'd much rather spend time analyzing specific concrete problems that real people are hitting, to come up with the right solution for the problem. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Wed, 26 Apr 2006, Archie Cobbs wrote:> For example (I'm making this up, you may have already considered and > rejected it): you could have a callback function (supplied by the > front end) that would be invoked any time an optimization pass needed > to {add, delete, move, modify} an LLVM instruction. In other words, > all the questions about "what to do with the annotation in situation X" > you simply delegate to the front end to deal with. So then you no longer > have to worry about what happens to the annotations during a transformation.The problem is that the set that "X" comes from is not bounded. We don't want to update every front-end whenever the capabilities of LLVM increase.> OK I'll shut up now and go read about annotation in the archives... :-)Please do, it has been extensively discussed in the past. -Chris -- http://nondot.org/sabre/ http://llvm.org/