llvm dev - Mar 2014 - [LLVMdev] 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


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>

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

On 03/20/2014 10:00 AM, Filip Pizlo wrote:
> 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
> <mailto: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 <mailto: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/bef1cf9c/attachment.html>