Function attribute for non-memory side effects?

I've got a library function which writes to external state, but which does not update any location addressable from the code being compiled. I'd like to mark this function as read only to enable store forwarding, but I still need to model the side effect. (Otherwise, LLVM will happily remove any calls to the function since it returns void.)

Does LLVM have a mechanism to describe something like this? I can't find anything along these lines.

Philip

I don’t think it does. I previously proposed TBAA on calls as a way of modeling arbitrary effects, and there seemed to be something like consensus that this is something we want.

I believe that TBAA on calls will give you what you want. You can basically name arbitrary heaps and claim to read/write them and the optimizer is obligated to take your word for it. For example, if you wanted to model the fact that a function never writes the Java heap but does write to memory, you could create a TBAA hierarchy like:

JVMRoot

± JVMHeap

± … hierarchy of heap things…

± JVMExternal

± JVMFilesystem

± … other things

Then having a call that claims to write JVMFilesystem but not anything in JVMHeap would give you what you want, provided that all of your loads/stores claims to load or store things within the JVMHeap hierarchy.

JavaScriptCore already uses this internally within our DFG IR. We have abstract heaps like “SideState” that do not represent anything actually in memory but are used by some of the more subtle operations to inform the compiler that there are effects that happen just that they are outside of what the VM would ordinarily think of as its heap. It would be awesome to do more of this in LLVM IR and I believe that TBAA on calls gives you what you need.

-Filip

Filip,

Thank you for this insight. This is absolutely a technique I’ll be applying in the future. This seems really, really powerful.

I actually figured out a way around my immediate problem right after sending my email. I can restructure my runtime call to explicitly expose the state update to my compiled code. I have to actually implement this, but in principal it should have the effect I desire.

Philip