| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
llvm-svn: 94686
|
|
|
|
| |
llvm-svn: 45418
|
|
|
|
| |
llvm-svn: 21427
|
|
|
|
|
|
|
| |
their implementation of book-keeping for which functions need to be materialized
and which don't.
llvm-svn: 10943
|
|
|
|
| |
llvm-svn: 10131
|
|
|
|
| |
llvm-svn: 9903
|
|
|
|
|
|
| |
Header files will be on the way.
llvm-svn: 9298
|
|
|
|
| |
llvm-svn: 9212
|
|
|
|
| |
llvm-svn: 9201
|
|
|
|
|
|
|
| |
and because, while the class used by the interface is abstract, the actual
concept is not.
llvm-svn: 8850
|
|
|
|
|
|
|
| |
because it can add a module ID which we do not have at this time.
* Check to see if the module has been initialized when materializing it.
llvm-svn: 8674
|
|
llvm-svn: 8594
|