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.
opt -basicaa -print-alias-sets basicaa.ll -S -o -
Alias Set Tracker: 1 alias sets for 2 pointer values.
AliasSet[0x109808c90, 2] may alias, Mod Pointers: (i64* %sunkaddr4,
18446744073709551615), (i32* %sunkaddr2, 18446744073709551615)
opt -basicaa -tbaa -print-alias-sets basicaa.ll -S -o -
Alias Set Tracker: 2 alias sets for 2 pointer values.
AliasSet[0x112d07cf0, 1] must alias, Mod Pointers: (i64*
%sunkaddr4, 18446744073709551615)
AliasSet[0x112d07d40, 1] must alias, Mod Pointers: (i32*
%sunkaddr2, 18446744073709551615)
define void @basicaatest(%str* %a) {
%sunkaddr1 = ptrtoint %str* %a to i32
%sunkadd = add i32 %sunkaddr1, 4
%sunkaddr2 = inttoptr i32 %sunkadd to i32*
%sunkaddr3 = ptrtoint %str* %a to i32
%sunkadd2 = add i32 %sunkaddr1, 4
%sunkaddr4 = inttoptr i32 %sunkadd2 to i64*
store i64 1, i64* %sunkaddr4, !tbaa !0
store i32 2, i32* %sunkaddr2, !tbaa !2
ret void
}
!0 = metadata !{metadata !"int64", metadata !1}
!1 = metadata !{}
!2 = metadata !{metadata !"int32", metadata !1}
On Thursday, November 8, 2012, Pranav Bhandarkar wrote:>
> 2) If the answer to the above is no, then shouldn't basicaa treat the
above
> conservatively before it looks at TBAA ?
>
>
> Thanks,
> Pranav
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121109/218f359b/attachment.html>
> 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.
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