search for: gcmoduleinfo

Hi all, This patch adds a GCModuleInfo field to the MachineFunction class, to facilitate the retrieval of a potential GCFunctionInfo attached to the function. The motivation for the change is to get access in a proper way to the GC info when generating the function with the JIT. Currently, retrieving this information requires a lot of h...

Hi all, So, MCJIT is working with vmkit, that's great. However, I need to retrieve the GCModuleInfo and the MachineCodeEmitter used during the compilation process. And I don't know how I should proceed? I'm trying to understand how they are preserved with the old jit, but I have to say that I'm a little bit lost because I haven't a global view of the code... So, any help would be...

...->getGlobalValueAddress("safepoint-symb"), mcjit is unable to find it in the object file. Any idea? Gaël 2013/12/15 Gaël Thomas <gael.thomas00 at gmail.com>: > Hi all, > > So, MCJIT is working with vmkit, that's great. However, I need to > retrieve the GCModuleInfo and the MachineCodeEmitter used during the > compilation process. And I don't know how I should proceed? I'm trying > to understand how they are preserved with the old jit, but I have to > say that I'm a little bit lost because I haven't a global view of the > code... So...

...it in the object file. > > Any idea? > Gaël > > > > > > > > > > > > 2013/12/15 Gaël Thomas <gael.thomas00 at gmail.com>: >> Hi all, >> >> So, MCJIT is working with vmkit, that's great. However, I need to >> retrieve the GCModuleInfo and the MachineCodeEmitter used during the >> compilation process. And I don't know how I should proceed? I'm trying >> to understand how they are preserved with the old jit, but I have to >> say that I'm a little bit lost because I haven't a global view of the &gt...

...2 libpthread.so.0 0x000000372560e7c0 3 libc.so.6 0x0000003dc9e30265 gsignal + 53 4 libc.so.6 0x0000003dc9e31d10 abort + 272 5 llc 0x0000000000e2e9b0 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 384 6 llc 0x0000000000a680f9 llvm::GCModuleInfo::getOrCreateStrategy(llvm::Module const*, std::string const&) + 265 7 llc 0x0000000000a683a7 llvm::GCModuleInfo::getFunctionInfo(llvm::Function const&) + 263 8 llc 0x0000000000a6919e 9 llc 0x0000000000d872c6 llvm::FPPassManager::doInitialization(llvm::...

Hello Philip, it seems like r226311 [1] introduced a bug which causes finishAssembly() to be called multiple times, even if there is only one strategy. For each function, GCModuleInfo::getFunctionInfo() adds the strategy to the StrategyList instance variable. AsmPrinter::doFinalization() calls finishAssembly() for each strategy in this list. -Manuel [1] http://reviews.llvm.org/rL226311

...it makes sense to do this cleanup job in doFinalization() of the pass, which requested GC info. So the current fix seems to be ok and all external clients will need to do cleanup directly doing the same jobs as Printer::doFinalization() does now. By the way, I've just noticed that comments for GCModuleInfo::clear() also needs to be updated, as it mentions deleter pass. -Dmitry. On Mon, Feb 25, 2013 at 9:55 PM, Yiannis Tsiouris <gtsiour at softlab.ntua.gr>wrote: > Hi Dmitry, > > > On 02/23/13 19:10, Dmitry Babokin wrote: > >> What's about the usage case, when LLVM is...

Yiannis, - /// clear - Resets the pass. The metadata deleter pass calls this. + /// clear - Resets the pass. The metadata printer pass calls this. I would propose different text here: /// clear - Resets the pass. Any pass, which uses GCModuleInfo(), should call it in doFinalization(). Does it make sense? -Dmitry On Wed, Feb 27, 2013 at 7:21 PM, Yiannis Tsiouris <gtsiour at softlab.ntua.gr>wrote: > ** > Hi , > > Can someone commit the attatched (cleanup) patch for r175528? > > Thanks, > yiannis > > > O...

...months from now, but likely less than 18 months. Hopefully, that's vague enough. :) HELP - If anyone knows which Ocaml implementation and which Erlang implementation triggered the in tree GC strategies, please let me know! Near Term Changes: - Migrate ownership of GCStrategy objects from GCModuleInfo to LLVMContext. In theory, this looses the ability for two different Modules to have the same collector with different state, but I know of no use case for this. - Modify the primary Function::getGC/setGC interface to return a reference the GCStrategy object, not a string. I will provide a F...

...leanup job in doFinalization() of the pass, which > requested GC info. So the current fix seems to be ok and all external > clients will need to do cleanup directly doing the same jobs as > Printer::doFinalization() does now. > > By the way, I've just noticed that comments for GCModuleInfo::clear() > also needs to be updated, as it mentions deleter pass. > > On Mon, Feb 25, 2013 at 9:55 PM, Yiannis Tsiouris > <gtsiour at softlab.ntua.gr <mailto:gtsiour at softlab.ntua.gr>> wrote: > > Hi Dmitry, > > > On 02/23/13 19:10, Dmitry Babokin w...

...t line: MMI = getAnalysisIfAvailable<MachineModuleInfo>(); This asserts if you use the AsmPrinter the way the DwarfLinker and the AsmPrinter based DwarfGen does if you call this. You must call this to generate the DebugDwarf. If you get past this by installing a Pass then we assert at: GCModuleInfo *MI = getAnalysisIfAvailable<GCModuleInfo>(); assert(MI && "AsmPrinter didn't require GCModuleInfo?"); If we don't have this, we don't get a DwarfDebug. > > Even if we end up adding another set of code to generate DWARF (which I'd really like to av...

...t;(); >> >> This asserts if you use the AsmPrinter the way the DwarfLinker and the >> AsmPrinter based DwarfGen does if you call this. You must call this to >> generate the DebugDwarf. If you get past this by installing a Pass then we >> assert at: >> >> GCModuleInfo *MI = getAnalysisIfAvailable<GCModuleInfo>(); >> assert(MI && "AsmPrinter didn't require GCModuleInfo?"); >> >> If we don't have this, we don't get a DwarfDebug. >> >>> >>> Even if we end up adding another set of code...

...asserts if you use the AsmPrinter the way the DwarfLinker and the > >> AsmPrinter based DwarfGen does if you call this. You must call this to > >> generate the DebugDwarf. If you get past this by installing a Pass then > we > >> assert at: > >> > >> GCModuleInfo *MI = getAnalysisIfAvailable<GCModuleInfo>(); > >> assert(MI && "AsmPrinter didn't require GCModuleInfo?"); > >> > >> If we don't have this, we don't get a DwarfDebug. > >> > >>> > >>> Even if we end up...

Hi Pedro (et al.), On 02/14/2013 11:43 PM, Pedro Artigas wrote: > I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called. > Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to ca...

...l thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC [setGC, hasGC, clearGC] Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. Please let me know if you have any questions! Thanks, Gordon P.S. Sorry for...

Hi Dmitry, On 02/23/13 19:10, Dmitry Babokin wrote: > What's about the usage case, when LLVM is used as a library and the > user implements its custom pass, which dump the code (implemented as a > FunctionPass, but not as Printer)? Hm, I haven't thought of that... I'll take a better look and try to find a more suitable solution. Any suggestion is more than welcome! :-)

...softlab.ntua.gr> wrote: > Hi Pedro (et al.), > > On 02/14/2013 11:43 PM, Pedro Artigas wrote: >> I believe what is going on is that there is an issue with the way that information is deleted (the CG information). > Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called. > >> Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chanc...

Pedro, Yiannis, What's about the usage case, when LLVM is used as a library and the user implements its custom pass, which dump the code (implemented as a FunctionPass, but not as Printer)? You also missed in your changes the declaration of llvm::createGCInfoDeleter() in include/llvm/CodeGen/Passes.h -Dmitry. On Mon, Feb 18, 2013 at 9:34 PM, Pedro Artigas <partigas at apple.com>

Hello Yiannis, I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to call the finishAssembly function. Right now the order that the doFinalization is called on passes is the reverse

Sorry for the triple-posting! :-$ On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote: > On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: >> After rebasing my local LLVM repo to ToT, I noticed that the >> finishAssembly function is not executed and, thus, the stack map is not >> printed at all. >> >> Is this a known issue or I 'm doing something wrong? >>