LLVM Versions of the Intrinsics

The process of implementing the GC/TM instruction set I described earlier has brought up some small revelations and oversights, which I'll list here.

First and foremost, the type taken and yielded by the safepoint instruction needs to be something called a "context", which should contain everything I described mbox as containing, except that it also needs a mailbox pointer itself. I'm torn as to exactly how to do this. The assumption I've been making is that safepoint would be translated into code that (if the safepoint actually ends up going into the scheduler or GC) stores all the information in a context back into the mailbox itself (hence the need for the mailbox pointer), calls into the runtime system, then extracts that same information out of the mailbox once the thread resumes. This would seem to produce alot of extraneous state in the program. However, LLVM's optimizations should eliminate any extraneous loads and stores if some component of the context isn't used between safepoints. Additionally, the instructions which store to or load from the mailbox can be positioned to minimize register pressure.

The spawn and gcalloc instructions need to take and produce a full context, not just a gcallocator, as allocation can potentially have the same effect as a safepoint.

The LLVM getelementptr, load, and store instructions ought to be modified, rather than creating new read or write instructions. Of particular interest is load/stores operating on structures. This will require extraction/injection of all the double-pointer fields in the structure, which will require special backend code-generation.

The touch instruction also needs more arguments. In the case of GC objects, I need a pointer to the object header, as well as a pointer to the thing that was touched. In the transactional case, I probably want to allow for "data groups", which would generalize the cache-line/object conflict detection presently used.

And lastly, I'm unsure about what should happen with transactions when you hit a safepoint. At the least, validation of the entire transaction before and after actually suspending would be a good idea. There should also be some kind of deprioritization that can take place. I'll be looking into this more as I get further into implementation.