[LLVMdev] Function attribute for non-memory side effects?

[Filip Pizlo]

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


On Mar 20, 2014, at 9:50 AM, Philip Reames <listmail at philipreames.com> wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140320/4d9407ee/attachment.html>