llvm dev - May 2016 - How to extend alias analysis to enable further optimisations?

Hello,

We have developed a compiler analysis for multi-threaded codes that
identifies functions which do not modify global variables. Furthermore, the
analysis checks that accesses performed before the function call, do not
target the same location as accesses performed after the call (hence, the
variables accessed before and after the call do not alias).

We want to integrate this analysis within the existing analyses, such that
standard compiler optimisations can use this info. Do you suggest that we
change the getModRefInfo() or there is a better way to expose the
no-aliasing information to the optimisations?
If getModRefInfo() is the way to go, can you please indicate how to start?
Where can I find documentation about the way getModRefInfo() works and how
it is used by the optimisation passes. Any suggestion on particular passes
that use it can be a good start.

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/6e47cc71/attachment.html>

----- Original Message -----
> From: "Daniel Edin via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Tuesday, May 10, 2016 3:26:38 PM
> Subject: [llvm-dev] How to extend alias analysis to enable further
optimisations?
> 
> 
> 
> Hello,
> 
> We have developed a compiler analysis for multi-threaded codes that
> identifies functions which do not modify global variables.
> Furthermore, the analysis checks that accesses performe before the
> function call, do not target the same location as accesses performed
> after the call (hence, the variables accessed before and after the
> call do not alias).
> 
> We want to integrate this analysis within the existing analyses, such
> that standard compiler optimisations can use this info. Do you
> suggest that we change the getModRefInfo() or there is a better way
> to expose the no-aliasing information to the optimisations?
> If getModRefInfo() is the way to go, can you please indicate how to
> start? Where can I find documentation about the way getModRefInfo()
> works and how it is used by the optimisation passes. Any suggestion
> on particular passes that use it can be a good start.
You can implement your own AA analysis pass which provides this information.
Modeling your implementation after lib/Analysis/GlobalsModRef.cpp seems like a
reasonable plan.

 -Hal
> 
> Thank you!
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On 05/10/2016 02:13 PM, Hal Finkel via llvm-dev wrote:
> ----- Original Message -----
>> From: "Daniel Edin via llvm-dev" <llvm-dev at
lists.llvm.org>
>> To: llvm-dev at lists.llvm.org
>> Sent: Tuesday, May 10, 2016 3:26:38 PM
>> Subject: [llvm-dev] How to extend alias analysis to enable further
optimisations?
>>
>>
>>
>> Hello,
>>
>> We have developed a compiler analysis for multi-threaded codes that
>> identifies functions which do not modify global variables.
>> Furthermore, the analysis checks that accesses performe before the
>> function call, do not target the same location as accesses performed
>> after the call (hence, the variables accessed before and after the
>> call do not alias).
>>
>> We want to integrate this analysis within the existing analyses, such
>> that standard compiler optimisations can use this info. Do you
>> suggest that we change the getModRefInfo() or there is a better way
>> to expose the no-aliasing information to the optimisations?
>> If getModRefInfo() is the way to go, can you please indicate how to
>> start? Where can I find documentation about the way getModRefInfo()
>> works and how it is used by the optimisation passes. Any suggestion
>> on particular passes that use it can be a good start.
> You can implement your own AA analysis pass which provides this
information. Modeling your implementation after lib/Analysis/GlobalsModRef.cpp
seems like a reasonable plan.
You should also take a close look at the existing aliasing metadata.  
TBAA can be used to describe many aliasing facts.  Don't get caught up 
in the fact it's called "type based"; you get to define whatever
"type
system" you want.  :)
>
>   -Hal
>
>> Thank you!
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>