search for: gcmetadata

...>>> - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? >>>>>> - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an arr...

...st to be sure in the future! Does this seem reasonable? yianns -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- A non-text attachment was scrubbed... Name: GCMetadata.patch Type: text/x-diff Size: 2199 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130216/0609b1f0/attachment.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 2...

...s I am misreading your proposal, your proposed StackMap intrinsic > duplicates existing functionality already in llvm. In particular, much of > the StackMap construction seems similar to the Safepoint mechanism used by > the in-tree GC support. (See CodeGen/GCStrategy.cpp and > CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you > can share implementations? > - To my knowledge, there is nothing that prevents an LLVM optimization pass > from manufacturing new pointers which point inside an existing data > structure. (e.g. an interior pointer to an array wh...

...;>> intrinsic duplicates existing functionality already in llvm. In >>>>> particular, much of the StackMap construction seems similar to the >>>>> Safepoint mechanism used by the in-tree GC support. (See >>>>> CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you >>>>> examined these mechanisms to see if you can share implementations? >>>>> - To my knowledge, there is nothing that prevents an LLVM >>>>> optimization pass from manufacturing new pointers which point >>>>> inside an...

...c static void main(String[] args) { System.out.println("Hello world\n"); }}shyam at shyam:~$ javac hello.java -o hello.classshyam at shyam:~$ vmjc hello.class -o hello.bcshyam at shyam:~$ lli hello.bc unsupported GC: vmkitUNREACHABLE executed at /home/shyam/llvm-3.1.src/lib/CodeGen/GCMetadata.cpp:99!0 lli 0x089a5778Stack dump:0. Program arguments: lli hello.ll Aborted Please help me out -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/1a67e632/attachment.html>

...ves 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: > <GCMetadata.patch>

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 also thinks that it is OK. I also tried to add a simple unit-test by using the avail...

when I execute clang on llvm bitcode files, I get the following error: clang: error: unable to execute command: Aborted unsupported GC: vmkit UNREACHABLE executed at GCMetadata.cpp:87! 0 clang 0x09e9d5d9 llvm::sys::PrintStackTrace(_IO_FILE*) + 41 Stack dump: 0. Program arguments: /home/ali/llvm-3.3.src/Release+Asserts/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name somefile.bc -mrelocation-model static -mdisable-fp-elim -fm...

...(minor) - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when blocking a loo...

...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: > > > <GCMetadata.patch> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... UR...

...minor) > - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? > - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when blocking a l...

...>>> - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? >>> - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when bloc...

...>>> - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? >>>> - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when...

...r) >> - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? >> - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when blocking...

...e+Debug+Asserts/bin/vmjc --main=hello hello.class -f -o /tmp/llvm_WbIrdX/hello.bc llc /home/shyam/llvmbuild/Release+Debug+Asserts/bin/llc /tmp/llvm_WbIrdX/hello.bc -disable-fp-elim -o /tmp/llvm_WbIrdX/hello.s (null) unsupported GC: vmkitUNREACHABLE executed at /home/shyam/llvm-3.1.src/lib/CodeGen/GCMetadata.cpp:99!0 llc 0x08c83b58Stack dump:0. Program arguments: /home/shyam/llvmbuild/Release+Debug+Asserts/bin/llc /tmp/llvm_WbIrdX/hello.bc -disable-fp-elim -o /tmp/llvm_WbIrdX/hello.s 1. Running pass 'Function Pass Manager' on module '/tmp/llvm_WbIrdX/hello.bc'. After observing the make...

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

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

...ndex: include/llvm/CodeGen/GCStrategy.h =================================================================== --- include/llvm/CodeGen/GCStrategy.h (revision 141409) +++ include/llvm/CodeGen/GCStrategy.h (working copy) @@ -37,6 +37,7 @@ #define LLVM_CODEGEN_GCSTRATEGY_H #include "llvm/CodeGen/GCMetadata.h" +#include "llvm/CodeGen/MachineFunction.h" #include "llvm/Support/Registry.h" #include <string> @@ -68,6 +69,8 @@ bool CustomReadBarriers; //< Default is to insert loads. bool CustomWriteBarriers; //< Default is to insert stores. bool Cus...

This is a proposal for adding Stackmaps and Patchpoints to LLVM. The first client of these features is the JavaScript compiler within the open source WebKit project. A Stackmap is a record of variable locations (registers and stack offsets) at a particular instruction address. A Patchpoint is an instruction address at which space is reserved for patching a new instruction sequence at runtime.

...m misreading your proposal, your proposed StackMap intrinsic > duplicates existing functionality already in llvm. In particular, much > of the StackMap construction seems similar to the Safepoint mechanism > used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and > CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if > you can share implementations? > - To my knowledge, there is nothing that prevents an LLVM optimization > pass from manufacturing new pointers which point inside an existing data > structure. (e.g. an interior pointer to an array...