[LLVMdev] Default Alias analysis passes for PassManager

[Will Dietz]

On Thu, Sep 29, 2011 at 9:33 AM, Max Bolingbroke
<batterseapower at hotmail.com> wrote:
> Hi,
>
> I'm writing a custom alias analyser for the Glasgow Haskell Compiler's
> LLVM backend to teach LLVM that our explicitly-represented stack
> cannot alias with any heap pointer.
>

Great!

> It works, but I've hit an issue with opt's handling of alias
> analysers; if you specify -ghc-aa on the opt command line then LLVM
> only uses that analyser until (I think) a pass runs that invalidates
> the results of alias analysis. My workaround was to:
>  1. Use "opt -O2 -debug-pass=Structure" to get the list of flags
> equivalent to using -O2
>  2. Insert -ghc-aa between each flag, to force them to use my alias analyser
>  3. Use "opt ... huge-list-of-flags ..." to actually do the optimisation
>

Is your pass an immutable pass?  If so you'll have the best luck,
since it can't be invalidated.

IIRC when I tried interleaving my pass like you said, because you
haven't installed it as "default" there are cases (due to pass
dependencies and things like loop pass transformations) where your
analysis gets invalidated so won't be used for portions of the code.
Something to keep in mind.

>  1. Has/will PassManager be changed to allow a default alias analyser
> stack to be set somehow?

I'm interested in this too.

>  2. If I insert -ghc-aa between each pass, will LLVM only use the
> results of my analyser, or will it chain it with -basic-aa? (Perhaps I
> should say "-basic-aa -ghc-aa" instead?) The output of
> -debug-pass=Structure is not very clear on which alias analyser
> applies where.

If things haven't changed too much from when I last looked at them
(~2.7), it will always 'run' basicAA, regardless of what you specify
on the command line, and will always be chained.

FWIW if you do have a stateful analysis pass, keep in mind there are a
few bugs regarding using such an alias analysis (being queried while
invalidated, being queried on values that didn't exist when your pass
was last run).  Again, I haven't tracked these since 2.7 so it's
possible they were fixed, but for example
http://llvm.org/bugs/show_bug.cgi?id=7615 is still open.

Good luck!

~Will