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

[Philip Reames]

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>