similar to: GEP with a null pointer base

I’m not entirely opposed to solution #3. As I said, my concern is that there are cases it would miss. For instance, if I had some code like this: char *get_ptr(char *base, intptr_t offset) { return base + offset; } char *convert_to_ptr(intptr_t ptr_val) { return get_ptr((char*)0, ptr_val); } There the idiom would only appear after inlining, so the front end couldn’t handle it. The

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else? I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom. The most recent glibc code is a bit more complicated than I represented below. If you look up obstack.h you can see what’s there now.

Can we go back a little? 1) Add a new transformation to InstCombine that will replace 'getelementptr > i8, i8* null, <ty> %n' with 'inttoptr <ty> %n to i8*' when <ty> has the > same size as a pointer for the target architecture. What's the actual problem with this approach? I personally find it the most compelling - it is well-defined (well,

> On Jul 6, 2017, at 3:07 PM, Chris Lattner <clattner at nondot.org> wrote: > > >> On Jul 6, 2017, at 2:05 PM, Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >>> On Jul 6, 2017, at 1:00 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

> On Jul 6, 2017, at 1:00 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> So far, so good. The problem is that while LLVM seems to consider >> the above IR to be valid, we officially do not allow dereferencing >> a pointer constructed in this way (if I’m reading the rules >> correctly). Consequently, if this GEP ever gets close enough to

On 15 Feb 2014, at 23:55, Andrew Trick <atrick at apple.com> wrote: > On Feb 14, 2014, at 5:18 PM, Philip Reames <listmail at philipreames.com> wrote: > >> RFC: GEP as canonical form for pointer addressing >> >> I would like to propose that we designate GEPs as the canonical form for pointer addressing in LLVM IR before CodeGenPrepare. >> >>

On 02/17/2014 02:53 PM, Andrew Trick wrote: > On Feb 17, 2014, at 2:31 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 15 Feb 2014, at 23:55, Andrew Trick <atrick at apple.com> wrote: >> >>> On Feb 14, 2014, at 5:18 PM, Philip Reames <listmail at philipreames.com> wrote: >>> >>>> RFC: GEP as canonical form for

RFC: GEP as canonical form for pointer addressing I would like to propose that we designate GEPs as the canonical form for pointer addressing in LLVM IR before CodeGenPrepare. Corollaries 1) It is legal for an optimizer to convert inttoptr+arithmetic+inttoptr sequences to GEPs, but not vice versa. 2) Input IR which does not contain inttoptr instructions will never contain inttoptr

Just for reference, my C example was for my own clarification. I dived into LLVM having to write a TargetMachine and I've been keeping busy without having to learn much IR (yet). I was really trying to use C as a pseudo-IR. I get that the idea is allowing IR to directly express the address of part of a vector complicates (prevents?) certain optimizations. However, due to my own

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> > Sent: Wednesday, November 20, 2013 7:48:13 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > >

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Junbum Lim" <junbums at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, November 20, 2013 7:01:49 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com>

On Nov 20, 2013, at 10:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Evan Cheng" <evan.cheng at apple.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >> Sent: Wednesday, November 20, 2013

On Nov 21, 2013, at 4:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Nov 20, 2013, at 10:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> ----- Original Message ----- >>> From: "Evan Cheng" <evan.cheng at apple.com> >>> To: "Hal Finkel" <hfinkel at anl.gov> >>> Cc: "LLVM" <llvmdev at

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

Chris, nice segue to Swift ! :-), but... The question is what should LLVM do with UB in general, saying that we are going to change one specific idiom from undefined to defined glosses over the real question: why should we ever optimize / delete any UB at all ? This “depressing and faintly terrifying thing” as you call it, should be viewed not as an opportunity for optimization, but

On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Evan Cheng" <evan.cheng at apple.com> >> To: "Junbum Lim" <junbums at gmail.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, November 20, 2013 7:01:49 PM >> Subject: Re: [LLVMdev] sinking address computing in

Dear all, I compiled c program with llvm and found something strange with function pointer as following small example . ------------- In C Code -------------- float a (int value) { return value + 1; }; typedef float (*funcptr_t) (int); funcptr_t get_ptr(funcptr_t p) { return p; } float result = get_ptr(a)(4); ------------- In LLVM Code -------------- %4 = call float (i32)* (float

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

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value