search for: inteljitevenst

...> s/ExecutionEngine/EE/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld (maybe RuntimeDyld -> DynamicLoader ? Too direct?) But not sure this is really an accurate model for the logical layering of these libraries?

...zword!) > > I don't really know the best bikeshed color here. Jim? > > My lame idea would be: > > ExecutionEngine -> JIT > ExecutionEngine -> JIT/Legacy > ExecutionEngine/MCJIT -> JIT/MC > ExecutionEngine/OProfileJIT -> JIT/OProfile > ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents > ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld > So long as we have the interpreter, we should keep the ExecutionEngine abstraction around. That said, I'd personally like to kill the interpreter… Eventually, lots of this can (and should) be simplified and f...

2012/11/22 Chandler Carruth <chandlerc at google.com>: > Hello LLVM & Clang hackers! > > Based on a discussion with Chris, I would like to propose a Great > Renaming of Things for the 3.3-era LLVM and Clang codebase. > > First and foremost, the two most significant changes I would like to make: > > 1) llvm/lib/VMCore/... -> llvm/lib/IR/... > > I've

Hello LLVM & Clang hackers! Based on a discussion with Chris, I would like to propose a Great Renaming of Things for the 3.3-era LLVM and Clang codebase. First and foremost, the two most significant changes I would like to make: 1) llvm/lib/VMCore/... -> llvm/lib/IR/... I've discussed potential names for the VMCore (or LLVMCore) library with lots of folks, and the best idea anyone