search for: bycode

...to rethink about a VM wich could run the IR bytecode directly? llvm has differents bytecode from low level, to more hight level... So do you see some interest to have this kind of VM for one of this bytcode ? Is it hight level enougth like java byte code ? My second obvious question is about the bycode format, is it stable enought to concider using it as an 'archive' source/byte code ? Thanks for some guidances, before investing lots of energy ! Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

...re hight level... So do you see some interest to have this kind of VM for one of this bytcode ? > Is it hight level enougth like java byte code ? Java bytecode remains much much higher-level than LLVM IR; this hasn't significantly changed. > > My second obvious question is about the bycode format, is it stable enought to concider using it as an 'archive' source/byte code ? Quite a few people are interested in keeping the bitcode format stable these days, so it will probably remain fairly stable for the foreseeable future. That said, as far as I'm aware all of the issue...

...on for all the runtime type information to get compiled into the core object module. Also I could bypass code thats difficult to compile and just stuff its bytcode into this section. So I think this really helps with partial compliation and supporting languags that have complex runtimes. The llvm bycode section would just get a stub runtime upcall for code that not compiled. For java for example this would probably be the compiled parts with stubs and a regular classfile for the runtime data with compiled functions converted to native. In the short term I think I'll simply use the class file...

Hi Reid, Reid Spencer schrieb: > I have some thoughts on this too .. > Great! > On Fri, 2006-02-24 at 19:56 +0100, Jakob Praher wrote: > >>I get you 100 % here. But as you say later in the mail, many information >>is done by some runtime std::map<Value*,foo> stuff. Which is really >>handy at runtime, but I *had* serialization in mind when I was thinking

...t; type information to get compiled into the core object module. Also I > could bypass code thats difficult to compile and just stuff its > bytcode into this section. So I think this really helps with partial > compliation and supporting languags that have complex runtimes. > The llvm bycode section would just get a stub runtime upcall for code > that not compiled. > Hmm. Not sure I understand you 100 % here. I think the most interesting use for annotations is if you want to augment information at some point in the bytecode. For instance if you want to say, you label exactly th...

Hi, A feature I've wanted in lit for a while is a having a timeout per test. Attached are patches that implement this idea. I'm e-mailing llvm-dev rather than llvm-commits because I want to gather more feedback on my initial implementation and hopefully some answers to some unresolved issues with my implementation. Currently in lit you can set a global timeout for all of the tests but