[llvm-dev] How to extend alias analysis to enable further optimisations?

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Wed May 11 21:44:06 PDT 2016


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
>>



More information about the llvm-dev mailing list