similar to: [LLVMdev] Confuse on ptrtoint and load

On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>> I have a question about when we should apply these pointer aliasing >>> rules. Do the rules tell

On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> I have a question about when we should apply these pointer aliasing >> rules. Do the rules tell us when a load/store is safe? >> "Any memory access must be done through a pointer value

On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." >

On Wed, Apr 20, 2011 at 2:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>>> I

On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > While I'm very interested in the end result here, I have some questions > that don't seem well answered yet around pointer subtraction... > > First and foremost - how do you address correctness issues here? Because > the subtraction `A - B` can escape/capture more

On Mon, Jan 14, 2019 at 4:51 PM Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, Jan 14, 2019, 15:59 Mehdi AMINI <joker.eph at gmail.com wrote: > >> >> >> On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> While I'm very interested in the end result here, I have

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

Hello Chandler, > ``` > void f(int *arr1, int *arr2, int length) { > intptr_t rel_offset = arr2 - arr1; > int *arr1_end = arr1 + length; > for (int *p = arr1; p < arr1_end; p += sizeof(int)) { > do_something(p, p + rel_offset); > } > } > ``` > > For example, a common loop optimization technique is something like the following in *pseudocode* (note

Hello Chandler, > First and foremost - how do you address correctness issues here? Because the subtraction `A - B` can escape/capture more things. Specifically, if one of `A` or `B` is escaped/captured, the > subtraction can be used to escape or capture the other pointer. So *some* of the conservative treatment is necessary. What is the plan to update all the analyses to remain correct?

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated 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

Thanks. So what about a fragment like this: (taken from fast-isel.ll in X86 ) define void @ptrtoint_i1(i8* %p, i1* %q) nounwind { %t = ptrtoint i8* %p to i1 store i1 %t, i1* %q ret void } TIA. On 09/29/2014 02:16 PM, Duncan P. N. Exon Smith wrote: >> On Sep 29, 2014, at 1:51 PM, reed kotler <rkotler at mips.com> wrote: >> >> What kind of C or C++ code will emit

Hi, guys! I write a virtual machine which uses LLVM as back-end code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void

Hi all, We noticed a lot of unnecessary ptrtoint instructions that stand in way of some of our optimizations; the code pattern looks like this: bb1: %int1 = ptrtoint %struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1.

[AMD Official Use Only - Internal Distribution Only] Hi everyone, Asan instrumentation introduces a ptrtoint instruction which is used as an argument to a number of runtime functions. Every instrumented load/store ends up having at least one ptrtoint attached to its address. However, the community has now raised a number of concerns about the use of LLVM generated ptrtoint & inttoptr [1]

On 06/20/2017 03:26 AM, Hal Finkel wrote: > Hi, Adrien, Hello Hal! Thanks for your answer! > Thanks for reporting this. I recommend that you file a bug report at > https://bugs.llvm.org/ Will do! > Whenever I see reports of missed optimization opportunities in the face > of ptrtoint/inttoptr, my first question is: why are these instructions > present in the first place? At

Technically I don't need C/C++ code for it. I'm not really very good at writing LLVM assembly code by hand (but I should be - lol ). I'm working on fast-isel and I want to have executable tests for all of this and not just make check tests. It's easier for me to do that in C/C++ and then save the .ll and morph it into a make check test. I'm going through the fast-isel

This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;

My general feeling is this: No optimizations should be creating int2ptr/ptr2int. We really need to fix them all. They should use pointer casts and i8* GEPs. This has, unfortunately, been a problem for a long time. As Johannes says, optimizing int2ptr/ptr2int is very tricky. In part, becaue all dependencies, including implicit control dependencies, end up being part of the resulting aliasing

On Wednesday 22 July 2009 13:30, Dan Gohman wrote: > - A pointer value formed by a ptrtoint is associated with all address > ranges of all pointer values that contribute (directly or > indirectly) to the computation of the pointer's value. Do you mean inttoptr here? And that "all pointer values that contribute (directly or indirectly) to the computation of the