AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue

Project Infrastructure LLVM Dev List Archives
1

Hi all,

First time posting to llvmdev, be gentle :).

I'm working on an AliasAnalysis implementation and running into an
issue on 2.7, that doesn't exist in 2.6 as far as I can tell.

Short version: has anyone been able to load an AliasAnalysis module
into 2.7's opt?

Longer version:

Even with a dummy pass implementation (just returns MayAlias for
everything), I'm getting very strange behavior:

All calls to FooAA::alias go to FooAA::print, resulting in
understandably painful failure thereafter, generally a segfault.

Example stack trace:
==25630== by 0xB2752F: llvm::Pass::print(llvm::raw_ostream&,
llvm::Module const*) const (Pass.cpp:94)
==25630== by 0x9B2769:
llvm::MemoryDependenceAnalysis::getPointerDependencyFrom(llvm::Value*,
unsigned long, bool, llvm::ilist_iterator<llvm::Instruction>,
llvm::BasicBlock*) (MemoryDependenceAnalysis.cpp:282)

And the related lines from MemDep:
282 if (AccessPtr == Inst ||
283 AA->alias(Inst, 1, AccessPtr, 1) == AliasAnalysis::MustAlias)

The way I make this happen is to run:

opt -load fooAA.so -foo-aa -dse

(where "-foo-aa" is the AA pass defined in the module fooAA.so, and
dse makes use of the aa results through memdep)

Finally a short bit about my build env: GCC 4.4.3, Debug build, Linux x86_64.

I'd be happy to provide any more information required/desired, but
hopefully that covers the basics.

Any thoughts? Is this a bug, or am I potentially doing something silly?

Thanks for your time,

~Will

2

Are you sure you built your module against LLVM 2.7 headers?

-Eli

3

Thanks for the response, Eli.

The header suggestion could certainly cause this issue (I panicked for
a second), but unfortunately as far as I can tell the headers are in
fact from LLVM 2.7.

The pass is built as a project configured by llvm, so hopefully that
would make things right, but also:
--include paths look legit (make VERBOSE=1, etc)
--strace on the build process for the project confirms no headers
outside the llvm 2.7 tree are read, and 'svn diff' confirms I haven't
managed to botch those.

The code is from the "release_27" branch, for what it's worth.

I'm not at all convinced I haven't somehow broken my build
environment, but it's not clear to me how.

Thoughts on anything else I could look into?

For what it's worth, attached is the project triggering the issue, if
someone gets bored and either wants to try it or tell me what I'm
doing wrong :).

Thanks for your time,

~Will

test-aa.tar.bz2 (32.1 KB)

4

Dear Will,

If you're seeing the wrong method executed, it's probably because you're using multiple inheritance in your analysis group (which is a very common thing to do).

LLVM 2.7 made a change which alleviated the need for RTTI or some other undesirable C++ feature. However, it also broke multiple inheritance with analysis group passes. To fix it, your analysis group needs to implement a getAdjustedAnalysisPointer() method. The implementation should look something like this:

/// When chaining analyses, changing the pointer to the correct pass
virtual void *getAdjustedAnalysisPointer(const PassInfo *PI) {
    if (PI->isPassID(&ArrayBoundsCheckGroup::ID))
        return (ArrayBoundsCheckGroup*)this;
    return this;
}

Just replace "ArrayBoundsCheckGroup" with whatever the name of your analysis group is, and it should work.

-- John T.

Will Dietz wrote:

5

Hi John,

Thank you very much for your reply and explanation. This was indeed
my issue and fixes it nicely.

Have a good one,

~Will