llvm dev - Mar 2017 - Informing transformation passes of non-concurrent memory accesses

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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/528d3e11/attachment.html>

On 03/14/2017 05: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?
You'll need to modify the LICM code to use this information (look for 
calls to isSimple()).

Can you describe what your analysis does?

  -Hal
>
> 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
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

Hi Andreas,

2017-03-14 11:56 GMT+01:00 Andreas Scherman via llvm-dev <
llvm-dev at lists.llvm.org>:
> 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.
>
As a possible clarification: The optimization restriction you cite only
applies to stores to possibly shared variables. Speculative loads are legal.

In the example in the docs, the offending bit is not loading x into a local
variable xtemp, but unconditionally storing xtemp back into x. Emphasis on
`unconditionally`. I.e., if it weren't for the `if (a[i])` in the original
piece of code, the transformation would be legal!

Best,
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/63114eb7/attachment.html>

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>