search for: gcmetadataprint

Hi, 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? I used a custom GCMetadataPrinter plugin but I reproduced this using the builtin "ocaml" GC plugin and the attached file (actually, any simple ll file that uses "ocaml" gc is fine). Note: The beginAssembly function works great. Best wishes, yiannis -- Yiannis Tsiouris Ph.D. student, Software Engineering La...

.../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? > > I used a custom GCMetadataPrinter plugin but I reproduced this using the > builtin "ocaml" GC plugin and the attached file (actually, any simple ll > file that uses "ocaml" gc is fine). > > Note: The beginAssembly function works great. > I've tried adding two debug prints in lib/CodeGen...

...edro 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 call the finishAssembly function. Right now the order that the doFinalization is called on passes is t...

...ter 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? >>> >>> I used a custom GCMetadataPrinter plugin but I reproduced this using the >>> builtin "ocaml" GC plugin and the attached file (actually, any simple ll >>> file that uses "ocaml" gc is fine). >>> >>> Note: The beginAssembly function works great. >> I've tried adding...

...siouris 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? >> >> I used a custom GCMetadataPrinter plugin but I reproduced this using the >> builtin "ocaml" GC plugin and the attached file (actually, any simple ll >> file that uses "ocaml" gc is fine). >> >> Note: The beginAssembly function works great. > I've tried adding two debug prints in...

...rtigas 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 call the finishAssembly function. Right now the order that the doFinalization is called on pa...

...en component) had to be decoupled from the AsmWriter interface. This required moving the beginAssembly and endAssembly methods to a separate abstract base class. If you had overridden these methods, your class may compile successfully but fail at runtime with a message of the form: no GCMetadataPrinter registered for collector: %s The fix is to transition your overrides to a subclass of GCMetadataPrinter: 1. Subclass GCMetadataPrinter and move your beginAssembly and endAssembly implementations there. The GCMetadataPrinter has the same data accessors as Collector (now GCStrategy), so y...

Hello Yiannis, Your patch seems fine. It is option #2 which I am glad to hear solves the issue. It also removes more lines than it adds, I like patches that fix issues and have that property! Anyhow if you add some testing, as you suggest, you should be good to go. Thanks Pedro On Feb 16, 2013, at 6:13 AM, 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 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! :-)

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

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

On 02/15/2013 07:13 PM, Pedro Artigas wrote: > I am not an expert on metadata or the CG information but one of the two has to happen: I'm not an expert either but I'll give it a try! :-) > - Simply moving the deleter pass to a different spot > - Changing the doFinalization of another pass (Printer?) to do the deleter pass job (this should work now because the doFinalization order

Hi , Can someone commit the attatched (cleanup) patch for r175528? Thanks, yiannis On 02/25/2013 08:11 PM, Dmitry Babokin wrote: > Yiannis, Pedro, > > I'm not an expert here. Taking closer look I see that 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

...Extend the GCStrategy class to include a notion of which compilation strategy is being used. The two choices right now will be Legacy and Statepoint. (Longer term, this will likely become a more fine grained choice.) - Separate GCStategy and related pieces from the GCFunctionInfo/GCModuleInfo/GCMetadataPrinter lowering code. At first, this will simply mean clarifying documentation and rearranging code a bit. - Document/clarify the callbacks used to customize the lowering. Decide which of these make sense to preserve and document. (Lest anyone get the wrong idea, the above changes are intended to be...

I updated my from LLVM 2.7 to 2.8/trunk tonight and was mystified as to why my GC plugin silently stopped working. The problem was that the signature of the virtual function GCMetadataPrinter::finishAssembly (and beginAssembly) changed. This change would probably be an excellent candidate for the "gotchas" section of the 2.8 release notes. Thanks! -- Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm...

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>

Yiannis, Pedro, I'm not an expert here. Taking closer look I see that 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()

Hi! I have now a more precise question, I hope that this time, someone will be able to help me :) I'm now able to find the gc meta data. To find this data, I simply register a GCMetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that at this step, a collection point (aka safepoint in the GC world) is describe by: * a MCSymbol, whi...

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

Hi Ben, > I updated my from LLVM 2.7 to 2.8/trunk tonight and was mystified as to why my > GC plugin silently stopped working. > > The problem was that the signature of the virtual function > GCMetadataPrinter::finishAssembly (and beginAssembly) changed. > > This change would probably be an excellent candidate for the "gotchas" section > of the 2.8 release notes. can you please send some text appropriate for the release notes that explains the problem. Thanks a lot, Duncan.