similar to: [LLVMdev] [PATCH] Fix GCMetadaPrinter::finishAssembly not executed

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] [PATCH] Fix GCMetadaPrinter::finishAssembly not executed"

2013 Feb 16
2
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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
2013 Feb 25
2
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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()
2013 Feb 15
2
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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.
2013 Feb 27
0
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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
2013 Feb 15
0
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
Hello Yiannis, I am not an expert on metadata or the CG information but one of the two has to happen: - 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 is the reverse of the doInitialization order) Option 1 is a smaller change, option 2 will make the code
2013 Feb 27
1
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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
2013 Feb 23
3
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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>
2013 Feb 14
2
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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? >>
2013 Feb 10
2
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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
2013 Feb 14
0
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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
2013 Feb 25
0
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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! :-)
2013 Feb 14
0
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
Ping for this. 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? > > I used a custom GCMetadataPrinter plugin but I reproduced this using the > builtin
2013 Feb 18
0
[LLVMdev] GCMetadataPrinter::finishAssembly not executed?
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: >
2012 Sep 07
3
[LLVMdev] Publication - ErLLVM: An LLVM backend for Erlang
Sorry for double-posting to the list, The citation is the following (this time with a url to the paper): K. Sagonas, C. Stavrakakis, and Y. Tsiouris. "ErLLVM: An LLVM backend for Erlang"[1]. In Eleventh ACM SIGPLAN Erlang Workshop, September 2012. ACM Press. Thanks! Yiannis [1]: http://erllvm.softlab.ntua.gr/files/erlang03-sagonas.pdf On 09/07/2012 08:13 PM, Yiannis Tsiouris wrote:
2012 Sep 10
0
[LLVMdev] Publication - ErLLVM: An LLVM backend for Erlang
ping. :-) On 09/07/2012 08:24 PM, Yiannis Tsiouris wrote: > [...] > The citation is the following (this time with a url to the paper): K. > Sagonas, C. Stavrakakis, and Y. Tsiouris. "ErLLVM: An LLVM backend > for Erlang"[1]. In Eleventh ACM SIGPLAN Erlang Workshop, September > 2012. ACM Press. > > [1]: http://erllvm.softlab.ntua.gr/files/erlang03-sagonas.pdf >
2012 Sep 11
1
[LLVMdev] Publication - ErLLVM: An LLVM backend for Erlang
On 9/10/12 5:29 PM, Yiannis Tsiouris wrote: > ping. :-) I've been on vacation since August 28 and disabled llvmdev delivery so that I wouldn't get flooded with emails while I was gone, so I didn't see your message. I've added the entry to the publications page, but I haven't made a separate page for the abstract. Is that alright, or would you like an abstract page
2012 Apr 14
2
[LLVMdev] RFC: ErLLVM - An LLVM backend for Erlang
Hi, We 've been working on an LLVM backend for High Performance Erlang (HiPE) [1], the native code compiler of Erlang/OTP [2]. ErLLVM [3] targets the X86 and AMD64 architectures for now but there is some ongoing work from a team on the Uppsala University to also support ARM. In our implementation, we have paid special attention on retaining ABI-compatibility with the Erlang Runtime System in
2012 Apr 24
0
[LLVMdev] RFC: ErLLVM - An LLVM backend for Erlang
Hi, Following Chris' advice, I will rebase the patches and break them in 3 distinct emails (one at a time) in order to be easier for a reviewer to approve/comments. Please note that the three patches while being code-wise independent, they 're strongly-connected *semantically*, meaning that including just a subset of these patches to LLVM's code base is quite weak if the others are
2012 Apr 06
2
[LLVMdev] Potential Google Summer of Code Applicant
On 4/6/12 2:21 AM, Talin wrote: > I would really like to see someone work on LLVM's garbage collection > support - it hasn't been updated in 4 years, and while there's been a > lot of talk about ways that it could be improved, there's been no action. That is *sooo* true! :-) I'm one of the authors of an LLVM backend for Erlang (ErLLVM [1]); we have tested and
2015 Jan 25
2
[LLVMdev] GCMetadataPrinter::finishAssembly called twice
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