[LLVMdev] Analysis Passes

[Gordon Henriksen]

On Jul 25, 2008, at 16:57, John Criswell wrote:

> Devang Patel wrote:
>
>> On Jul 25, 2008, at 12:58 PM, Marc de Kruijf wrote:
>>
>> I'd like to write a pass that does both: implements a code  
>> transformation and saves information that can be accessed by  
>> subsequent passes.
>>
>> Ideally, we want to use two separate pass. However, it is quiet  
>> possible that your requirement is unique. Would it be possible to  
>> provide more info. on what your pass does ?
>
> We actually have a similar situation with Automatic Pool Allocation  
> (APA) and SAFECode.  Some of the SAFECode passes need to query the  
> Automatic Pool Allocation transform pass to determine what it has  
> done. Examples include:
>
> 1) Given a pointer, what pool did APA use to allocate objects to  
> which the pointer can point?
> 2) Is a function a clone of an original function, and if so, which  
> function is the original function?
> 3) What is the LLVM type of a pool descriptor?  Different versions  
> of APA use a different type.
>
> I think we could refactor APA into an analysis pass and transform  
> pass. The analysis pass does nothing on its own but has update  
> methods that other passes can use to update it's information.  When  
> APA is run, it updates the analysis pass, and when the SAFECode  
> passes run, they get the APA information from the analysis pass.


This use case is not adequately serviced by the current LLVM pass  
manager.

I had a similar problem with the GC metadata information. Ultimately,  
I had to structure it as an ImmutablePass (with an explicit pass to  
free the contained information) because it would be invalidated by  
other passes at random. This is essentially the same approach used to  
manage the MachineFunction representation.

Speaking of which, I also have also attempted to eliminate Annotatable  
by storing the MachineFunction in a FunctionPass analysis used only to  
maintain the MachineFunction representation. That experiment failed  
for essentially the same reason. (It would've succeeded if I'd thought  
to use an ImmutablePass at the time.)

Unsatisfactory.

— Gordon