search for: gvcalue

...le for generating and initializing allocas for every root. It also > means a lot fewer opportunities for generating incorrect code. > > What do you think? > So a few additional thoughts: I think that it would be best to keep the existing llvm.gcroot() call in addition to having llvm.gvcalue(). llvm.gcroot() would be used for marking allocas as roots, and llvm.gcvalue() would mark SSA values as roots. In fact, if I could go back in time, I would rename them to correspond exactly with the llvm.dbg intrinsics. So in addition to llvm.dbg.declare() and llvm.dbg.value(), we'd also have...

I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC

...zing allocas for every root. It also >> means a lot fewer opportunities for generating incorrect code. >> >> What do you think? >> > > So a few additional thoughts: I think that it would be best to keep the > existing llvm.gcroot() call in addition to having llvm.gvcalue(). > llvm.gcroot() would be used for marking allocas as roots, and llvm.gcvalue() > would mark SSA values as roots. > > In fact, if I could go back in time, I would rename them to correspond > exactly with the llvm.dbg intrinsics. So in addition to llvm.dbg.declare() > and llvm.db...