search for: ptrint

Hi, Johannes, Thanks for working on this. This seems like a good approach which nicely extends the set of capabilities we have now. One additional comment, as I agree with everything in your rationale, except this: > - Reconstructing information from the pattern of instructions that feed > into the `llvm.assume` is also not optimal, especially since we do > not need to

...ee one of these values to trace roots, but each of these still needs its own entry in the stack/register map for a moving collector. PrePtrMap, we need a type system to precisely tag all values known to contain valid heap pointers. No potentially uninitialized/undefined values allowed here. IntPtr/PtrInt casts become control dependent. PostPtrMap, we need an IR that represents mapped pointers as live-in to safepoints, *and* safepoints need to be defined as clobbering all locations that may contain a pointer. For example, if we have a register map, then we can no longer move and add instruction acr...

On Jan 29, 2010, at 12:09 PM, Samuel Crow wrote: > Hello Russell, > > Major pitfall #1: > LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. > > I've been

Talin, how about having the front-end generate an llvm.safe.point () intrinsic call at the desired safe points, and having the addresses of the GC roots (at that point, can vary from call to call) be the parameters (with noescape attribute) to the intrinsic, IIUC currently the GC roots are tagged, and all analysis and transform optimizations have to special case these tagged