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

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>

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:
> 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
>>     
> >

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

On Wed, May 26, 2010 at 9:09 AM, John Criswell <criswell at illinois.edu>
wrote:
> 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:
>>
>> 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
>>>
>>
>> >
>
>