search for: pointeraliasing

...>>   %200 = inttoptr i64 %199 to i8*                 ; <i8*> [#uses=1] >> into >> %200 = getelementptr %193, %196 >> Reducing the unnecessary casts of converting to integers and then back? >> Thanks, >> Arushi >> See http://llvm.org/docs/LangRef.html#pointeraliasing ; it's not correct in general. It is correct if %196 isn't dependent on the address of any memory object, though. -Eli

...t; undefined." >>>> >>>> So this means the conversion discussed here is still safe in terms of >>>> memory safety, but its meaning after conversion could be weird. Am I >>>> correct? >>> >>> Per http://llvm.org/docs/LangRef.html#pointeraliasing, it's undefined >>> behavior, so it isn't safe in any sense.  In practice, I can't think >>> of a common transformation that would cause a crash, but it's best not >>> to depend on that. >> >> My confusion could be what is considered to be unde...

...64 %199 to i8* ;<i8*> [#uses=1] >>> into >>> %200 = getelementptr %193, %196 >>> Reducing the unnecessary casts of converting to integers and then back? >>> Thanks, >>> Arushi >>> > See http://llvm.org/docs/LangRef.html#pointeraliasing ; it's not > correct in general. It is correct if %196 isn't dependent on the > address of any memory object, though. Can you clarify why the transform isn't correct? Is it because in the original code, %200 is based on both the originally cast pointer (%193) and the indexed...

...memory access, otherwise the behavior is >> undefined." >> >> So this means the conversion discussed here is still safe in terms of >> memory safety, but its meaning after conversion could be weird. Am I >> correct? > > Per http://llvm.org/docs/LangRef.html#pointeraliasing, it's undefined > behavior, so it isn't safe in any sense.  In practice, I can't think > of a common transformation that would cause a crash, but it's best not > to depend on that. My confusion could be what is considered to be undefined from the rules. It says a memory ac...

...e behavior is >>> undefined." >>> >>> So this means the conversion discussed here is still safe in terms of >>> memory safety, but its meaning after conversion could be weird. Am I >>> correct? >> >> Per http://llvm.org/docs/LangRef.html#pointeraliasing, it's undefined >> behavior, so it isn't safe in any sense.  In practice, I can't think >> of a common transformation that would cause a crash, but it's best not >> to depend on that. > > My confusion could be what is considered to be undefined from the >...

...to i64 %add = add i64 %pti, 5 %itp = inttoptr i64 %add to i8* ret i8* %itp} define i8* @g(i8* %A) { %gep = getelementptr i8* %A, i64 5 ret i8* %gep} What, if anything, prevents us from canonicalizing @f to @g?I've heard that this might be in violation of http://llvm.org/docs/LangRef.html#pointeraliasing but I don't see how. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140830/8cdfddda/attachment.html>

...with an address range of the memory access, otherwise the behavior is > undefined." > > So this means the conversion discussed here is still safe in terms of > memory safety, but its meaning after conversion could be weird. Am I > correct? Per http://llvm.org/docs/LangRef.html#pointeraliasing, it's undefined behavior, so it isn't safe in any sense. In practice, I can't think of a common transformation that would cause a crash, but it's best not to depend on that. > Then it comes to my another question. The base-on relation has this rule: > "A pointer value f...

...;>>> into > >>>> %200 = getelementptr %193, %196 > >>>> Reducing the unnecessary casts of converting to integers and then back? > >>>> Thanks, > >>>> Arushi > >>>> > >> See http://llvm.org/docs/LangRef.html#pointeraliasing ; it's not > >> correct in general.  It is correct if %196 isn't dependent on the > >> address of any memory object, though. > > > > Can you clarify why the transform isn't correct?  Is it because in the > > original code, %200 is based on both the or...

...o distinguish between them if they have the same base, but not the same type. Is it wrong to get BasicAliasAnalysis to look at the type of the base pointer and take a more aggressive approach if the base pointer type is the same ? I got this impression on reading http://llvm.org/docs/LangRef.html#pointeraliasing as it seems to suggest that types are not associated with memory. Can this situation be helped ? Thanks, Pranav Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...  ;<i8*>  [#uses=1] >>>> into >>>> %200 = getelementptr %193, %196 >>>> Reducing the unnecessary casts of converting to integers and then back? >>>> Thanks, >>>> Arushi >>>> >> See http://llvm.org/docs/LangRef.html#pointeraliasing ; it's not >> correct in general.  It is correct if %196 isn't dependent on the >> address of any memory object, though. > > Can you clarify why the transform isn't correct?  Is it because in the > original code, %200 is based on both the originally cast pointer (%1...

...ator, you can recognize it. Additionally, I believe that functions with return values marked with the noalias attribute are, essentially, memory allocators because the return value is guaranteed to not alias with anything not based off of the return value. See http://llvm.org/docs/LangRef.html#pointeraliasing for more details. As an aside, I've been thinking for awhile that we should have a "memory allocator" analysis group that identifies different allocators for different source-level languages (i.e., one analysis would recognize malloc, free, realloc, calloc while another would rec...

...4] #<<, [256 x i64], [256 x i64] } to the second { [256 x i64], [256 x i64]#<<, [256 x i64] }. I believe, one reason for having it defined this way is to be able to handle C's zero (variable) length arrays. LLVM's concept of memory is untyped (http://llvm.org/docs/LangRef.html#pointeraliasing). You can get types through TBAA. We would need to strengthen TBAA to handle this for C. On Feb 5, 2013, at 9:51 AM, Renato Golin <renato.golin at linaro.org> wrote: > Hi all, > > One of the reasons the Livermore Loops couldn't be vectorized is that it was using global struc...

Hi all, One of the reasons the Livermore Loops couldn't be vectorized is that it was using global structures to hold the arrays. Today, I'm investigating why is that so and how to fix it. My investigation brought me to LoopVectorizationLegality::canVectorizeMemory(): if (WriteObjects.count(*it)) { DEBUG(dbgs() << "LV: Found a possible read/write reorder:"

Hi, Is it correct to convert, %196 = load i32* %195, align 8 ; <i32> [#uses=1] %197 = zext i32 %196 to i64 ; <i64> [#uses=1] %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] %199 = add i64 %198, %197 ; <i64> [#uses=1] %200 = inttoptr i64 %199 to i8* ; <i8*>

Hi, > > Is it correct to convert, > > %196 = load i32* %195, align 8 ; <i32> [#uses=1] > %197 = zext i32 %196 to i64 ; <i64> [#uses=1] > %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] > %199 = add i64 %198, %197 ; <i64> [#uses=1] > %200 = inttoptr i64 %199 to i8*

...n them if they have the > same base, but not the same type. Is it wrong to get BasicAliasAnalysis to > look at the type of the base pointer and take a more aggressive approach if > the base pointer type is the same ? I got this impression on reading > http://llvm.org/docs/LangRef.html#pointeraliasing as it seems to suggest > that types are not associated with memory. > > Can this situation be helped ? > 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...

I tried to compile this snippet of C++ code: void FuncTest() {     int* a = new int;     int* b = new int[2]; } using: clang test.cpp -S -emit-llvm -o - > test.llvm and obtained this: define void @_Z8FuncTestv() { entry:   %a = alloca i32*, align 4   %b = alloca i32*, align 4   %call = call noalias i8* @_Znwj(i32 4)   %0 = bitcast i8* %call to i32*   store i32* %0, i32** %a, align 4  

...8*> [#uses=1] >>>> into >>>> %200 = getelementptr %193, %196 >>>> Reducing the unnecessary casts of converting to integers and then back? >>>> Thanks, >>>> Arushi >>>> >>>> See http://llvm.org/docs/LangRef.html#pointeraliasing ; it's not >> correct in general. It is correct if %196 isn't dependent on the >> address of any memory object, though. >> > > Can you clarify why the transform isn't correct? Is it because in the > original code, %200 is based on both the originally cast po...

...>>>>>> %200 = getelementptr %193, %196 >>>>>> Reducing the unnecessary casts of converting to integers and then back? >>>>>> Thanks, >>>>>> Arushi >>>>>> >>>> See http://llvm.org/docs/LangRef.html#pointeraliasing ; it's not >>>> correct in general. It is correct if %196 isn't dependent on the >>>> address of any memory object, though. >>> Can you clarify why the transform isn't correct? Is it because in the >>> original code, %200 is based on both the...

...i64] #<<, [256 x i64], [256 x i64] } to the second { [256 x i64], [256 x i64]#<<, [256 x i64] }. I believe, one reason for having it defined this way is to be able to handle C's zero (variable) length arrays. LLVM's concept of memory is untyped (http://llvm.org/docs/LangRef.html#pointeraliasing). You can get types through TBAA. > We would need to strengthen TBAA to handle this for C. > I think that the potential for overlap is indeed there, but don't we already insert runtime overlap checks as necessary? This seems like it would just be another such case. -Hal > > &...