similar to: [LLVMdev] Bug in LowerIntrinsics::PerformDefaultLowering ?

|I noticed that in line 288-289 of lib/CodeGen/GCStrategy.cpp there is a |loop: |> for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB) { |> for (BasicBlock::iterator II = BB->begin(), E = BB->end(); |> II != E;) { |E is used both for F.end() and for BB->end(). Is this intended? Note that it's also being

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 , 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

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>

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:

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

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 >

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! :-)

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

As discussed in LLVMdev [1], due to the execution order of doFinalization functions, the GC information were deleted before AsmPrinter::doFinalization was executed. Thus, the GCMetadataPrinter::finishAssembly was never called. The attached patch fixes that by moving the code of the GCInfoDeleter::doFinalization to Printer::doFinalization. Pedro (cc'ed) has already taken a look at this and he

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

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

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

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.

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

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

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

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

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

Hello all, I set: InitRoots = true; in my gc plugin as i want the roots to be initialized to the "null" value. Is there a way to define which value should be the initial one? For example, i would like to initialize my roots to -5 (tagged, null value for the GC in my runtime system) instead of 0. Ofcourse, i could do it in the frontend (storing -5 to all GC roots), but i was wondering