search for: lowergc

This isn't really a bug, but it's generally bad style to declare variables with the same name in almost the same scope... The Visual C compiler can't compile things like this, so here is a patch. m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL:

...mmits/Week-of-Mon-20040719/016344.html > (Please tell me if I shouldn't mail patches directly on the mailing > list.) In general patches should be sent to the llvmbugs list, but this subject has some design discussion, so it's ok for it to be on llvmdev :) > While I was editing LowerGC.cpp I made a little test (not part of this > patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new > intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer > directly instead and transforms it into an alloca. The idea is the ... > In this way,...

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the following, this: %X = call sbyte...

Hi, I was evaluating all transformation passes and noticed a few things. In particular, I found three passes in the documentation that I can't seem to find any code for. Where these removed? Lower GC intrinsics, for GCless code generators (-lowergc) Correlated Expression Elimination (-cee) Lower select instructions to branches (-lowerselect) Additionally, I found the following passes for which no documentation was present: createGVExtractionPass() createStructRetPromotionPass() createStripDeadPrototypesPass() createJumpThreadingPass()...

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

...08:42, Matthijs Kooijman wrote: > I was evaluating all transformation passes and noticed a few things. > In particular, I found three passes in the documentation that I > can't seem to find any code for. Where these removed? > Lower GC intrinsics, for GCless code generators (-lowergc) Yes; this pass at least has been removed. > Correlated Expression Elimination (-cee) > Lower select instructions to branches (-lowerselect) > > Additionally, I found the following passes for which no > documentation was present: > createGVExtractionPass() > createStruc...

.... However, please make sure that it really > isn't being run. The verifier can be hidden by various levels of > abstraction. Assuming that I get everything with -debug-pass=Structure, then it isn't: % llc -march=x86 -stats -f tests/IS/npbis.bc -debug-pass=Structure Pass Arguments: -lowergc -lowerinvoke -lowerswitch -unreachableblockelim Target Data Layout Module Pass Manager Function Pass Manager Lower GC intrinsics, for GCless code generators -- Lower GC intrinsics, for GCless code generators Lower invoke and unwind, for unwindless code generators -- Lower invoke and unw...

Hi Chris, Chris Lattner wrote: > I don't think you want to try to have the LLVM code generator build this > table. The table is a contract between the specific codegen you're using > and the GC runtime you're using. This contract is specific to the current > ocaml code generator. > > In the LLVM world, you should use the first-class support we already have

On Dec 7, 2007, at 1:43 AM, Wojciech Matyjewicz wrote: > Recently, I was looking into the bug #1227. I wanted to check if > reordering optimization passes could solve it. To start with, I > tried to > reproduce the output of llvm-g++ -O3 using the combination of llvm-g++ > -O0 and opt with the appropriate passes. However, I was unable to. I > use > SVN versions of llvm and

.... For a "cooperative" code generator, the codegen > should emit tables (similar to EH tables) that describe this, and > the llvm code generator callback should enumerate these. Yes, that's what I'm working on. Currently I have: - Suppressed llvm.gcroot lowering in the LowerGC pass [may wish to remove the pass from the default pipeline entirely] - Added a GCInfo analysis - Recorded in GCInfo the stack object indices for roots Presumably, then, another pass can come along and use the analysis to emit GC tables. I'm still rummaging around the code generators tryi...

...ram.tab.h ? llvm/utils/TableGen/Debug ? llvm/utils/TableGen/Depend ? llvm/utils/TableGen/FileLexer.cpp ? llvm/utils/TableGen/FileParser.cpp ? llvm/utils/TableGen/FileParser.h ? llvm/utils/TableGen/FileParser.output ? llvm/utils/fpcmp/Debug ? llvm/utils/fpcmp/Depend Index: llvm/lib/Transforms/Scalar/LowerGC.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerGC.cpp,v retrieving revision 1.4 diff -r1.4 LowerGC.cpp 112c112 < GCRead = M.getOrInsertFunction("llvm_gc_read", VoidPtr, VoidPtrPtr, 0); --- > GCR...

Hi, Recently, I was looking into the bug #1227. I wanted to check if reordering optimization passes could solve it. To start with, I tried to reproduce the output of llvm-g++ -O3 using the combination of llvm-g++ -O0 and opt with the appropriate passes. However, I was unable to. I use SVN versions of llvm and llvm-gcc-4.2. First, I compile example.cpp (attached; taken from the bug #1227) with: $

On Thu, 22 Jul 2004, Chris Lattner wrote: > > While I was editing LowerGC.cpp I made a little test (not part of this > > patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new > > intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer > > directly instead and transforms it into an alloca. The idea is the > ....

...re, then it isn't: -debug-pass=Structure does list everything. If you add it, please add it in an "#ifndef NDEBUG" block so that it does not penalize the release build. Thanks! -Chris > % llc -march=x86 -stats -f tests/IS/npbis.bc -debug-pass=Structure > Pass Arguments: -lowergc -lowerinvoke -lowerswitch -unreachableblockelim > Target Data Layout > Module Pass Manager > Function Pass Manager > Lower GC intrinsics, for GCless code generators > -- Lower GC intrinsics, for GCless code generators > Lower invoke and unwind, for unwindless code generato...

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

On Aug 14, 2007, at 4:35 AM, Gordon Henriksen wrote: > On Aug 14, 2007, at 06:24, Gordon Henriksen wrote: > >> The two major problems I had really boil down to identifying GC >> points in machine code and statically identifying live roots at >> those GC points, both problems common to many collection >> techniques. Looking at the problem from that perspective

...re does list everything. If you add it, please add it > in an "#ifndef NDEBUG" block so that it does not penalize the release > build. > > Thanks! > > -Chris > > > % llc -march=x86 -stats -f tests/IS/npbis.bc -debug-pass=Structure > > Pass Arguments: -lowergc -lowerinvoke -lowerswitch -unreachableblockelim > > Target Data Layout > > Module Pass Manager > > Function Pass Manager > > Lower GC intrinsics, for GCless code generators > > -- Lower GC intrinsics, for GCless code generators > > Lower invoke and unwind...

...ped) ------------------------------------------------------------------------------ My allocator is assigning EAX to %reg1024, and this is exactly what any of the LLVM built-in allocators do. The list of passes that I am invoking is as follows: Pass Arguments: -verify -loopsimplify -loop-reduce -lowergc -lowerinvoke -unreachableblockelim Target Data Layout Debug Information Module Pass Manager Function Pass Manager Immediate Dominators Construction ET Forest Construction Module Verifier -- Module Verifier Natural Loop Construction Dominator Set Construction Dominator Tre...

...------------------------------------------------------- > > My allocator is assigning EAX to %reg1024, and this is exactly what any of > the LLVM built-in allocators do. The list of passes that I am invoking is > as follows: > > Pass Arguments: -verify -loopsimplify -loop-reduce -lowergc -lowerinvoke > -unreachableblockelim > Target Data Layout > Debug Information > Module Pass Manager > Function Pass Manager > Immediate Dominators Construction > ET Forest Construction > Module Verifier > -- Module Verifier > Natural Loop Construction &gt...