search for: dynamicload

...? 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?

...quot;JIT" and everything flattens. Bottom line for me is that I don't mind the naming of most of this stuff as-is, but I very much would like to see some simplification, renaming and restructuring as the MCJIT pushes forwards and old broken stuff gets nuked. > (maybe RuntimeDyld -> DynamicLoader ? Too direct?) I like the current name for RuntimeDyld. That's some of my Darwin bias showing, though. > But not sure this is really an accurate model for the logical layering > of these libraries? There's a logical layering for these libraries? ;) Seriously speaking, it's pr...

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