similar to: [LLVMdev] [!] Breaking changes to GC infrastructure

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

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

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

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

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.

On Mon, Sep 13, 2010 at 5:17 AM, Duncan Sands <baldrick at free.fr> wrote: > 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. >

Hi Chris, Gordon, Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points. I'm not sure who maintains the GC code today in LLVM (I'd be happy to take ownership, if needed). The patch just adds up a custom safepoints flag, similar to the way the GCStrategy can customize intrinsics lowering, or roots initialization. It works pretty well, as

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

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

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.

Hi, I have the solution to my problem :). And the llvm gc infrastructure can work with the current MCJIT without any change (good news). I will explain what I have done to find the garbage collector metadata generated by llvm with MCJIT, I'm pretty sure that it could help someone. And it's very easy. You just have to activate a static gcprinter for the assembly. A very good example is

Subsections is a very good idea. You can even do without post-processing by using carefully crafted section names, e.g. __attribute__((section(".text,\"ax\", at progbits\n\t.subsection 1 #"))) void foo() { } (Note that you need ".subsection n" commands on ELF targets and ".section name, n" commands on COFF targets; seems that the latter was supported on

On Thu, Jun 10, 2010 at 11:34 AM, David Terei <davidterei at gmail.com> wrote: > Its good to see that a feature of this nature would be useful to a > whole range of people, I wasn't aware of that. > > On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote: >> My argument amounts to express side tables as side tables in the IR >> rather than as

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

Hi all, Just wanted to report that I've found a second way to achieve data/code layout (the first being the linker script that Eugene mentioned). The key is that gnu as supports a feature called subsections. http://sourceware.org/binutils/docs-2.20/as/Sub_002dSections.html#Sub_002dSections The way this works is that you can put stuff into a section like '.text 2', where 2 is a

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

Sorry for the rapid fire replies, but this configuration works for me: install(DIRECTORY include/ DESTINATION include # FILES_MATCHING PATTERN "*.def" PATTERN "*.h" PATTERN "*.td" PATTERN "*.inc" PATTERN ".svn" EXCLUDE ) install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/ DESTINATION include # FILES_MATCHING PATTERN

llvm[4]: Compiling PoolAllocate.cpp for Release+Asserts build /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp: In member function ‘virtual bool llvm::PoolAllocate::runOnModule(llvm::Module&)’: /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp:403:16: error: ‘class llvm::Constant’ has no member named