similar to: [LLVMdev] A question about pointer aliasing rules in LLVM

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] A question about pointer aliasing rules in LLVM"

2012 Oct 25
0
[LLVMdev] A question about pointer aliasing rules in LLVM
On Thu, Oct 25, 2012 at 3:15 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Hi, > > I have the following IR code > > </snippet> > %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 > %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 > %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 > store %struct.myStruct*
2012 Oct 26
2
[LLVMdev] A question about pointer aliasing rules in LLVM
On 10/25/2012 5:36 PM, Dan Gohman wrote: > > First, yes, it is wrong for AliasAnalysis implementations to trust LLVM > IR types, for the most part. There's nothing in LLVM IR which would > prevent you from having two myStruct instances which overlap here, > sharing 4 bytes. Because of that, next really could be equal to &prev. > > In theory, you could help this
2012 Oct 19
2
[LLVMdev] Choosing an alias analyzer
Hi, In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, I see this code ------ // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. PM.add(createTypeBasedAliasAnalysisPass()); PM.add(createBasicAliasAnalysisPass()); } ------ My
2020 Jul 09
2
Understand alias-analysis results
Hey Matt, That's awesome. Thank you very much for all the information and clarification! Just a few follow up questions. Could you kindly shed some lights on it? Thank you! 1. I tried to tweak the code in the following way: - Clang [-> LLVM-IR]: https://llvm.godbolt.org/z/n9rGrs - [LLVM-IR ->] opt: https://llvm.godbolt.org/z/Uc6h5Y And i note that the outputs are: Alias sets for
2020 Jul 09
2
Understand alias-analysis results
Hello, I am performing alias analysis toward the following simple code: struct MyStruct { int * f1; int * f2; }; void NOALIAS(void* p, void* q){ } int main() { struct MyStruct s[2]; int a,b; s[0].f1 = &a; s[1].f1 = &b; NOALIAS(s[a].f1, s[b].f2); return 0; } When I use the following command to generate .bc code and conduct alias analysis: clang -c -emit-llvm t.c -O2 opt -basicaa
2012 Nov 01
2
[LLVMdev] llvm linking issue
I have three modules: ----------------------------------------------------------------- s1.ll: %0 = type <{ i32, i32 }> define void @s1(%0* byval %myStruct) nounwind { return: ret void } ----------------------------------------------------------------- s2.ll: %0 = type <{ i32, i32 }> define void @s2(%0* byval %myStruct) nounwind { return: ret void }
2012 Nov 01
0
[LLVMdev] llvm linking issue
Hi Xiaoyi, this looks like a bug to me - please file a bug report. Ciao, Duncan. On 01/11/12 04:35, Guo, Xiaoyi wrote: > I have three modules: > ----------------------------------------------------------------- > s1.ll: > > %0 = type <{ i32, i32 }> > > define void @s1(%0* byval %myStruct) nounwind { > return: > ret void > } >
2012 Oct 26
0
[LLVMdev] A question about pointer aliasing rules in LLVM
On Thu, Oct 25, 2012 at 5:32 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 10/25/2012 5:36 PM, Dan Gohman wrote: > >> >> First, yes, it is wrong for AliasAnalysis implementations to trust LLVM >> IR types, for the most part. There's nothing in LLVM IR which would >> prevent you from having two myStruct instances which overlap here,
2020 Jan 21
4
aarch64 does not emit DW_AT_Location
Hi Devs, debug info emitted by llvm does not contain DW_AT_Location for Formal parameter if it is an aggregate like below case 1) aggregate contain more than 4 homogeneous and size more than 128 bits i.e. typedef struct{ int a,b,c,d,e; }mystruct; void foo(mystruct ms){ } 2) aggregate contain hetrogeneous type and size more than 128 bits. i.e. typedef struct{ int a,b; float c,d,e; }mystruct; void
2002 Sep 29
1
[LLVMdev] the getelementptr noop problem
> so i confess i'm still not clear on what the first index into > getelementptr is all about. I'm sure you're not the only one. :) This is one of the wierdest aspects of LLVM to the unaccustomed. > it makes perfect sense for an example like > getelementptr %mystruct * %reg100 > to just return a %mystruct * equivalent to %reg100. > > it does *not* make sense to
2019 Mar 08
1
[RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: > > On 2019/3/8 ??3:16, Andrea Arcangeli wrote: > > On Thu, Mar 07, 2019 at 12:56:45PM -0500, Michael S. Tsirkin wrote: > > > On Thu, Mar 07, 2019 at 10:47:22AM -0500, Michael S. Tsirkin wrote: > > > > On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote: > > > > > +static const
2019 Mar 08
1
[RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: > > On 2019/3/8 ??3:16, Andrea Arcangeli wrote: > > On Thu, Mar 07, 2019 at 12:56:45PM -0500, Michael S. Tsirkin wrote: > > > On Thu, Mar 07, 2019 at 10:47:22AM -0500, Michael S. Tsirkin wrote: > > > > On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote: > > > > > +static const
2011 Oct 07
1
Handling Time in R
Dear all, I would like to ask your help regarding handling time stamps in R. I think first I need a reference to read about their logic and how I should handle them. For example, this is a struct I have str(MyStruct$TimeStamps)  num [1:100, 1:6] 2011 2011 2011 2011 2011 ... MyStruct$TimeStamps[1,] [1] 2011.000   10.000    6.000   16.000   23.000   30.539 the last field contains
2012 Oct 20
0
[LLVMdev] Choosing an alias analyzer
Hi Pranav, > In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, > I see this code > ------ > // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that > // BasicAliasAnalysis wins if they disagree. This is intended to help > // support "obvious" type-punning idioms. > PM.add(createTypeBasedAliasAnalysisPass()); >
2011 Jan 12
2
[LLVMdev] Wrong assembly is written for x86_64 target in JIT without optimization?
When I try running one llvm function in JIT without optimization I get SEGV. Looking at assembly (below) I see that the local value 0xffffffffffffffe0(%rbp) is used without being ever initialized (see my comment in asm). Same code on i386 works fine, with and w/out optimization. My guess is that this is a bug in LLVM. Yuri --- llvm --- %struct.mystruct = type { i32, i8, i8, i8, i8 } define
2012 Feb 07
1
[LLVMdev] tbaa differences in llvm 3.0
Is this issue still active? It sounded as though Dan or Hal were looking at it but I havent seen an response. Should I resubmit as 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
2012 Sep 19
0
[LLVMdev] newbie question on getelementptr
Hi Óscar, Thank you for your prompt reply. Unfortunately, I still need more guidance as using the Demo page to generate C++ code didn't result in a global variable being used. Basically, I'm following your advice to use a LoadInst: Value *v = new LoadInst(result, "", theBasicBlock); Function *myfn = cast<Function>(v); I was not sure how I could get a BasicBlock for the
2011 Oct 07
2
[LLVMdev] Aliasing confusion
Hi all, I'm having trouble understanding how llvm determines if pointers alias. Consider the following two functions that each do a redundant load: define float @A(float * noalias %ptr1) {   %ptr2 = getelementptr float* %ptr1, i32 1024   %val1a = load float* %ptr1   store float %val1a, float* %ptr2   %val1b = load float* %ptr1   ret float %val1b } define float @B(float * noalias %ptr1,
2012 Oct 12
2
[LLVMdev] Target backend not converting char* to struct properly.
I'm having trouble getting my backend to properly treat the situation where a char* is converted into a struct, i.e. something like: char* pointer_representation = ...; MyStruct* my_struct = (MyStruct*) pointer_representation; my_struct->an_int_field = 5; When this occurs, LLVM seems to fold the struct and char* into one assembly 'object', which is perfectly fine. However, it also
2009 Nov 05
0
[LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything
Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >