[llvm-dev] Informing transformation passes of non-concurrent memory accesses

[Philip Reames via llvm-dev]

On 03/14/2017 03:56 AM, Andreas Scherman via llvm-dev wrote:
> Hi!
>
> The example in the docs[1] states that the LLVM concurrency model does 
> not allow the hoisting of loads and introduction of local variables 
> due to another thread potentially altering the value whilst running 
> the function. Given that I have analysis which shows that the memory 
> location of variable /x /can not be concurrently accessed -- how would 
> I inform the LLVM transformation passes of this information?
I don't think we have the extension point you're asking for today. We 
have something really close though: pointerMayBeCaptured and 
pointerMayBeCapturedBefore.  These two try to establish the property 
that a given memory location is known to be thread local *because it 
hasn't yet escaped*.  What you're asking for is a bit different because 
the memory location might have escaped, but there's some external 
mechanism (e.g. locking) preventing another thread from accessing this 
location at this point in time.  We don't have anything which models 
that additional power or optimizes based on it.

Are you sure you need the power you asked for?  Or is there a weaker 
predicate which works?
>
> I tried injecting this information in to the AliasAnalysis under 
> getModRefInfo() by returning NoModref for the memory locations I knew 
> not to be accessed concurrently. However, it seemed that the usages of 
> the variables was not respected in that case, such that we could 
> reorder variables and change the semantics of the program.
>
> Thanks in advance,
>
> Andreas
>
> [1]: http://llvm.org/docs/Atomics.html#optimization-outside-atomic
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170317/8b0b09f4/attachment.html>