Displaying 9 results from an estimated 9 matches for "aliasgep".
Did you mean:
aliases
2018 Jun 18
2
Question about Alias Analysis with restrict keyword
...3] may alias, Mod/Ref Pointers: (i8* %11, 1),
(i8* %10, 1), (i8* %16, 1)
AliasSet[0x4a1e440, 1] must alias, Mod forwarding to 0x4a1e3a0
Alias analysis returns 'May- alias' for above code. When I look at the
alias analysis code, below code causes may-alias.
On BasicAAResult::aliasGEP()
1297 // Check to see if these two pointers are related by the
getelementptr
1298 // instruction. If one pointer is a GEP with a non-zero index
of the other
1299 // pointer, we know they cannot alias.
1300
1301 // If both accesses are unknown size, we can't do anything
use...
2012 Feb 07
1
[LLVMdev] tbaa differences in llvm 3.0
...s a bug so it gets
tracked?
thanks for your help
On Tue, Jan 31, 2012 at 1:35 PM, Dan Gohman <gohman at apple.com> wrote:
> On Jan 30, 2012, at 4:04 PM, Hal Finkel wrote:
> >
> > Dan, where in the code is this done? I see a comment at the end of
> > BasicAliasAnalysis::aliasGEP regarding "protecting TBAA in the case of
> > dynamic indices into arrays of unions"; are you referring to that?
>
> Yes. And looking at the testcase, this appears to be the problem.
>
> Dan
>
>
--
Not sent from my Blackberry, Raspberry or Gooseberry!
----------...
2012 Jan 31
3
[LLVMdev] tbaa differences in llvm 3.0
...right thing for C code in the real world.
> Possibly this is causing the loss of precision you're seeing.
Maurice, can you please provide a test case that demonstrates the
problem that you're seeing?
Dan, where in the code is this done? I see a comment at the end of
BasicAliasAnalysis::aliasGEP regarding "protecting TBAA in the case of
dynamic indices into arrays of unions"; are you referring to that?
-Hal
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>...
2012 Jan 31
0
[LLVMdev] tbaa differences in llvm 3.0
On Jan 30, 2012, at 4:04 PM, Hal Finkel wrote:
>
> Dan, where in the code is this done? I see a comment at the end of
> BasicAliasAnalysis::aliasGEP regarding "protecting TBAA in the case of
> dynamic indices into arrays of unions"; are you referring to that?
Yes. And looking at the testcase, this appears to be the problem.
Dan
2012 Nov 09
3
[LLVMdev] inttoptr and basicaa
...The reason is that nothing inside basicaa processes inttoptr; the fall
through case of using TBAA (int and long long in this case) is executed and
NoAlias is returned as the pointer types are different.
I have two questions.
1) Is it safe for basicaa to reason about inttoptr in a manner similar to
aliasGEP (using decomposeGEPExpression to symbolically evaluate the
pointer).
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 Fou...
2013 Feb 05
1
[LLVMdev] Vectorizing global struct pointers
On 5 February 2013 17:28, Nadav Rotem <nrotem at apple.com> wrote:
> We insert runtime overlap checks only for unidentified objects. The
> problem here is that the vectorizer thinks that A,B,C are all pointers to
> the same array, so it gives up. If A,B,C were different arrays then it
> could have used runtime checks.
>
Yes, that is exactly the code that creates the
2012 Nov 09
0
[LLVMdev] inttoptr and basicaa
...side basicaa processes inttoptr; the fall
> through case of using TBAA (int and long long in this case) is executed and
> NoAlias is returned as the pointer types are different.
>
> I have two questions.
> 1) Is it safe for basicaa to reason about inttoptr in a manner similar to
> aliasGEP (using decomposeGEPExpression to symbolically evaluate the
> pointer).
If we can prove the difference between two pointer values is a
compile-time constant (in this case, zero), we can return
NoAlias/MustAlias/etc. based purely on that. That said, GEP makes
special aliasing guarantees which ar...
2012 Jan 28
0
[LLVMdev] tbaa differences in llvm 3.0
On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote:
> Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to
2012 Jan 28
3
[LLVMdev] tbaa differences in llvm 3.0
Our application generates IR that is used to generate X86_64 code for a
Jit. We noticed that code generated with llvm 3.0 is worse in some
circumstances that it was with 2.9. I traced the differences to alias
analysis differences. Our IR references data structures that have lots of
derived pointers and we use extensive tbaa metadata to indicate which
pointers dont alias. Some of this seemed to be