llvm dev - May 2010 - [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue

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

On Tue, May 25, 2010 at 5:53 PM, Will Dietz <willdtz at gmail.com>
wrote:
> 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.
Are you sure you built your module against LLVM 2.7 headers?

-Eli

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

On Tue, May 25, 2010 at 10:13 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Tue, May 25, 2010 at 5:53 PM, Will Dietz <willdtz at gmail.com>
wrote:
>> 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.
>
> Are you sure you built your module against LLVM 2.7 headers?
>
> -Eli
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-aa.tar.bz2
Type: application/x-bzip2
Size: 32891 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100526/9be28e73/attachment.bin>