On 11/4/2011 3:29 AM, Nick Lewycky wrote:> I suspect that GCC is doing option 2, or something else I haven't > thought of (TBAA? if so, why doesn't our TBAA do as well?).Nick, The problem is that LLVM's implementation of TBAA does not distinguish between these two types: i32*** @AAA and i32** %arrayidx. We believe that type based alias analysis should, in general, be able to figure out that those two variables cannot meaningfully alias. -Anshu -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
On Nov 4, 2011, at 8:37 AM, Anshuman Dasgupta wrote:> On 11/4/2011 3:29 AM, Nick Lewycky wrote: >> I suspect that GCC is doing option 2, or something else I haven't >> thought of (TBAA? if so, why doesn't our TBAA do as well?). > > Nick, > > The problem is that LLVM's implementation of TBAA does not distinguish > between these two types: i32*** @AAA and i32** %arrayidx. We believe > that type based alias analysis should, in general, be able to figure out > that those two variables cannot meaningfully alias.Yes. The current TBAA implementation is conservative, with the idea that it can become more aggressive (and with TBAA, this fundamentally means "more dangerous") with incremental steps. It's interesting to note that clang's own source code is known to violate the TBAA rules for pointers (it's thought to be unlikely to cause trouble in practice). There are reasons for caution in this area. Dan
> Yes. The current TBAA implementation is conservative, with the idea that it > can become more aggressive (and with TBAA, this fundamentally means > "more dangerous") with incremental steps.Dan, Could you disclose more details about how to implement the "incremental steps" to handle more complicated alias cases? For example, differentiate different pointers that point to different types. and use this information to improve alias analysis accuracy?> It's interesting to note that clang's own source code is known to violate the TBAA > rules for pointers (it's thought to be unlikely to cause trouble in practice). There > are reasons for caution in this area.I don't get your point here. What "TBAA rules" are violated by "clang's own source code"? Where does this violation happen? and what caution we should have in this area? Thanks for your reply! -- Best Regards Gan