search for: anntat

...t for optimizations. But sometimes it would be interesting to actually get symbol information about a type beeing used, without the need for full featured debug information ala DWARF. This could be also solved by introducing Annotable. For instance if the alloca/malloc/.. instruction would get an Anntation about a symbolic type which could look like: { ("x",int) } One could use the DEF/USE and operand information in the byte code to know which symbolic field was accessed for instance through getelementptr. I don't know how you feel about that, but I there would be many circumstanc...

...eeing used, without the need for full featured debug > information ala DWARF. This isn't something you can do, this is far more tricky than you make it out to be. :) > This could be also solved by introducing Annotable. > For instance if the alloca/malloc/.. instruction would get an Anntation > about a symbolic type which could look like: > > { ("x",int) } > > One could use the DEF/USE and operand information in the byte code to > know which symbolic field was accessed for instance through getelementptr. Again, this is effectively extending the LLVM IR....

...a real option since one wants to work with production core libraries. (like I do now). Perhaps the thing could be solved by adding policy statemetns to annotations. I could imagine the inventor of an Annotation should think about how the annotation should behave during optimisation/change. So the anntation should have a policy field which defaults to DontCare. In that case the user of the Annotation cannot be sure that it will get retained or something like that. Given the discussion that happens in the higher level vms (like Gilad Bracha's Paper on pluggable type systems) gives some hints ab...

...nts to work with production core libraries. (like I do now). Okay. > Perhaps the thing could be solved by adding policy statemetns to > annotations. I could imagine the inventor of an Annotation should think > about how the annotation should behave during optimisation/change. So > the anntation should have a policy field which defaults to DontCare. In > that case the user of the Annotation cannot be sure that it will get > retained or something like that. Personally, I see annotations as a convenient way to do experiments and allow rapid development. If we decide that a featur...

...wants to work with production core libraries. (like I do now). > > Perhaps the thing could be solved by adding policy statemetns to > annotations. I could imagine the inventor of an Annotation should think > about how the annotation should behave during optimisation/change. So > the anntation should have a policy field which defaults to DontCare. In > that case the user of the Annotation cannot be sure that it will get > retained or something like that. > > Given the discussion that happens in the higher level vms (like Gilad > Bracha's Paper on pluggable type sys...