[LLVMdev] Whole program alias analysis in backend

[ihusar at fit.vutbr.cz]

Hello,
   thank you very much Stefan, we will take a look at the whole module  
passes
modifications. I seem quite complicated, but probably it is the only  
option.

   Regarding the alias analysis, maybe it could be done before in opt,
and to keep track of what happens to the loads and stores from LLVM IR
in the backend machine code, I do not know yet, we will have to think  
about that.

   Regarding the memory consumption, it is not much an issue for us I think,
At least for the opt passes a 20MG source code (generated) file occupies
something about 4G of memory which is still ok I think, I hope it will be  
similar
for the backend.

Thank you
   Adam



On Mon, 10 Jun 2013 16:02:36 +0200, Stefan Hepp <stefan at stefant.org> wrote:

> Hi,
>
> On 06/10/2013 09:13 AM, Jonas Wagner wrote:
>> Hi,
>>
>>        I know that backend processes one function at a time,
>>     is it somehow possible to do there a whole program analysis,
>>     or could you give me some guidelines?
>>
>>
>
> The backend introduces a MachineFunctionPass, from which point on it is  
> only possible to run FunctionPasses, otherwise the machine functions get  
> screwed.
>
> For our project, we also want do to whole-program analyses. I managed to  
> patch the PassManager, MachineFunctionPass and others to work with a new  
> MachineModule pass I introduced in our copy of LLVM. Now we can run  
> module passes in the backend, and have proper pass dependencies between  
> any combination of function passes and module passes (I haven't tested  
> my changes with any kind of basic block- or loop-passes).
>
> However, this was not an easy task.. it required some bugfixing deep  
> down in the PassManager infrastructure and some refactoring of the  
> backend passes (basically, the MachineFunction needs to be stored and  
> fetched from an ImmutablePass instead of keeping it (only) in the  
> MachineFunctionPass, the PassManager must be able to create new  
> MachineFunctionPasses itself, and the ImmutablePasses need to be passed  
> around in the PassManager properly). The downside is that the memory  
> consumption will go up since the backend must now keep all  
> MachineFunctions in memory instead of processing them one-by-one (I  
> avoid this overhead as long as no MachineModulePass is used though). I  
> also have not checked what happens if you remove or add functions in a  
> module pass.
>
> I hacked this into our backend which is based on LLVM 3.2. There have  
> been some changes to the way passes are initialized and finalized in  
> 3.3, but I think most of my patches will be the same for upstream. I am  
> thinking about posting the patches to the LLVM mailinglists, but for  
> this I need to find the relevant changes first, clean them up and port  
> to 3.3, and write some proper test-cases.. I won't have time to do this  
> properly in the near future, but if anybody is interested, I can try to  
> find the main commits and post them as they are. And if you are really  
> curious, you can find the git-repository here:
>
> https://github.com/t-crest/patmos-llvm
>
> Kind regards,
>   Stefan
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev