similar to: [LLVMdev] Alias Analysis Problem in LICM

Gan wrote: > Hi, > > I met an alias analysis problem in the LICM phase. I am using the following > piece of code to present this problem. > > 1 int size; > 2 int ** AAA; > 3 void * xalloc(int); > 4 > 5 void foo(void) > 6 { > 7 int i; > 8 AAA = (int**) xalloc(size * sizeof(int*)); > 9 >

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

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

On 11/3/11 4:07 PM, Gan wrote: > Hi, > > [snip] > > Since the "Anderson" alias analysis code is already moved out from > LLVM, we can only count > on BasicAA and TBAA for all alias analysis problems at this moment. > But these two piece of code > can only do very limited alias analysis and would become a big > performance bottleneck to > other

> 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

On Nov 7, 2011, at 10:17 PM, Gan wrote: >> 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

Hi I have this program in which fooBuf can only take on NULL or the address of local_fooBuf, and fooBuf and local_fooBuf have scope of the foo function. Therefore there is no way for the fooPtr argument to alias with fooBuf. However, LLVM basicaa and globalsmodref-aa say the 2 pointers may alias. I am thinking whether i should implement a limited form of point-to alias on the fooBuf pointer in

Hi Daniel, I see your point about LLVM and C/C++ type agnostic. I think TBAA was invented to partially cover this gap and give optimization opportunities when LLVM types are not sufficient but C/C++ types have required information. What do you think about following example: struct S { int a[10]; int b; }; int foo(struct S *ps, int i) { ps->a[i] = 1; ps->b = 2; return

When I compile two different modules using clang -O -S -emit-llvm I get different .ll files, no surprise. The first looks like double *v; double zap(long n) { double sum = 0; for (long i = 0; i < n; i++) sum += v[i]; return sum; } yielding @v = common global double* null, align 8 ; Function Attrs: nounwind readonly uwtable define double @zap(i64 %n) #0 { entry: %cmp4 =

> Yes. It's almost all up to the front-end. Find the place in clang > where it emits the "any pointer" metadata, and implement something > better. Dan, Thanks for replying! I have read the TBAA code in the front-end of clang. I did consider to extend it to handle more complicated pointer cases. For example, assigning different TBAA names to pointers pointing to different

On some targets with limited addressing modes, getting that 64-bit relocatable but loop-invariant value into a register requires several instructions. I'd like those several instruction outside the loop, where they belong. Yes, my experience is that something (I assume instcombine) recanonicalizes. Thanks, Preston On Tue, Dec 8, 2015 at 11:21 PM, Mehdi Amini <mehdi.amini at

On Thu, Sep 27, 2012 at 3:31 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, > > > On 27/09/12 08:02, Jun Koi wrote: >> >> On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: >>> >>> Hi Jun, did you tell "opt" to make use of TBAA? Also, please give >>> complete >>> IR >>> that

Hi John, Thank you for your reply! Please see my other questions below: > DSA is a unification-based points-to analysis.  The interface to use it as > an AliasAnalysis pass was removed since no one was using it and it was > probably buggy. - When you say "it was probably buggy", what is buggy? the "interface", or the AliasAnalysis? I'm so surprise that no one

On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, did you tell "opt" to make use of TBAA? Also, please give complete > IR > that people can use to reproduce, and instructions on how to reproduce (eg > how > to run opt). > actually, i am still confused on which options should be given to "opt" for it to use TBAA. any

Hal, Johannes, Thanks for the feedback. I have been digging into this a little bit more and was able to have some of this metadata being generated. Nevertheless, I am confused about the semantics of this metadata. Let me explain: I was expecting the alias metadata to complement the information that alias analysis passes compute. However, it seems that the alias information of the pointers used

I'm trying to make the IR "better", in a machine-independent fashion, without having to do any lowering. I've written code that rewrites GEPs as simple adds and multiplies, which helps a lot, but there's still some sort of re-canonicalization that's getting in my way. Is there perhaps a way to suppress it? Thanks, Preston On Wed, Dec 9, 2015 at 7:47 AM, Mehdi Amini

BTW, I have found why it doesn't work for arrays. TBAA information propagation is not implemented in CodeGenFunction::EmitArraySubscriptExpr with "TODO: Preserve/extend path TBAA metadata?". On Fri, Dec 4, 2015 at 1:38 PM, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote: > As far as I can see it is specifics of arrays inside structs. Current TBAA > does distinguish

Hi Jun, On 27/09/12 08:02, Jun Koi wrote: > On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: >> Hi Jun, did you tell "opt" to make use of TBAA? Also, please give complete >> IR >> that people can use to reproduce, and instructions on how to reproduce (eg >> how >> to run opt). >> > > actually, i am still

I suppose your view is reasonable, and perhaps common. My own "taste" has always preferred machine-independent code that is as simple as possible, so GEPs reduced to nothing more than an add, etc, i.e., quite risc-like. Then optimize it to reduce the total number of operations (as best we can), then raise the level during instruction selection, taking advantage of available instructions.

Jeroen, thank you for very useful link with the context. Indeed union cases are very complicated and I see places in code when TBAA gives up. Daniel, I completely agree that TBAA has limited power and can solve relatively simple cases only. So anything more complicated that involves intermediate variables that points to struct or array elements cannot be solved by TBAA alone. Differentiating