[LLVMdev] inttoptr and basicaa

[Arnold Schwaighofer]

No, TBBA is added first to the pass manager and as a result BasicAA
will run first - we give it a chance to recognize obviously bad
things. It comes up with mayalias and calls the next analysis (TBAA in
our case) in the chain by calling AliasAnalysis::alias in its
aliasCheck method.

Unfortuntaley, BasicAA does not look through the inttoptr so it does
not recognize that they must-alias. But it is doing nothing wrong by
returning may-alias or querying the next analysis.

On Fri, Nov 9, 2012 at 8:33 AM, Caldarale, Charles R
<Chuck.Caldarale at unisys.com> wrote:
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>> On Behalf Of Arnold Schwaighofer
>> Subject: [LLVMdev] inttoptr and basicaa
>
>> BasicAA treats it conservatively if used on its own. It will return mayalias
>> for the two pointers.
>
>> TBAA operates based on the guarantee that pointers to different types cannot
>> alias (think C's strict aliasing rules).  Therein lies its power but also its
>> danger, that is, nothing prevents the programmer to write code that violates
>> these rules (That's why we have -fno-strict-aliasing).
>
>> So when basica gives up returning mayalias we query tbaa, which will return -
>> based on strict aliasing rules of our language - noalias.
>
> Except... TBAA is called prior to basicaa, when using addInitialAliasAnalysisPasses().
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev