similar to: [LLVMdev] getelementptr being lowered to ptrtoint/.../inttoptr?

On Wed, Feb 29, 2012 at 11:00 AM, Dillon Sharlet <dsharlet at gmail.com> wrote: > Hello, > > I am working on an application of LLVM where I would strongly prefer that > getelementptr not be lowered into pointer arithmetic by any passes other > than my own. I'm writing a ModulePass. > > I am observing a situation where I compile a C++ file with no optimization >

Hello, Is there a way to clone a FunctionDecl, including the body Stmt if it exists? I want to add an entirely new decl to the AST with its own copy of the body. I would like to start with a completely identical Decl and body, and then modify it to produce a new overload, such that this cloned function would appear in overload resolution for calls to the original function. What I want to do is

On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <dan433584 at gmail.com> wrote: > It looks a little silly to say this in the case of the integer constant 5, > and there are some semantic gray areas around extra-VM allocation, but the > same thing happens if the add were adding a dynamic integer value, and then > it's difficult to find a way to separate that case from the constant

Consider the two functions bellow: define i8* @f(i8* %A) { %pti = ptrtoint i8* %A 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

On 09/08/2014 04:22 PM, Dan Gohman wrote: > An object can be allocated at virtual address 5 through extra-VM means > (eg. mmap), and then one can (creatively) interpret the return value > of @f as being associated with whatever %A was associated with *and* > 5. The return value of @g can only be associated with exactly the same > set that %A was associated with. Consequently,

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 ;

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*

On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/4/2011 6:45 PM, Eli Friedman wrote: >> >> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> >>  wrote: >>> >>>> Hi, >>>> Is it correct to convert, >>>>   %196 = load i32* %195, align 8                

On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> 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]

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

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> 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 =

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.

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

Hi All, I'm working on a project converting Dart to llvm. Dart uses a relocating GC but additionally uses pointer tagging. The first bit of a pointer is a tag. For integers a '0' bit is used and for pointers to objects a '1' bit is used. V8 apparently uses a similar technique. Generated code may need to check which bit is used when this information isn't statically known.

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 4/20/11 10:08 AM, Jianzhou Zhao 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." I don't think the pointer aliasing rules

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 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 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