similar to: GEP with a null pointer base

Hi everyone, I've got a problem that I would like some input on. The problem basically boils down to a program that I am compiling, whose source I don't control, doing something like this: p = (char*)0 + n where 'n' is an intptr_t-sized value that the program knows is actually a valid address for a pointer. clang translates this as %p = getelementptr inbounds i8, i8*

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

Hi Nick, On Tue, 26 Oct 2010, Nick Lewycky wrote: > Joel E. Denny wrote: > > Given this LLVM assembly: > > > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* > > getelementptr (i32* null, i32 1) to i64), i64 2)) > > > > llc fails an assertion: > > > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202:

Given 2 GEPs as follows, %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1] %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, !dbg !1051 ; <i16*> [#uses=1] can I replace the 2nd one with %tmp126 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, i64 0, i64 0 ; <i16*> When I try 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

> 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

Hi, Below is the snippet of LLVM IR code generated by Flang ---snip-- %3 = getelementptr i64, i64* %"a$sd", i64 11, !dbg !16 %4 = bitcast i64* %3 to i32*, !dbg !16 %5 = load i32, i32* %4, align 4, !dbg !16, !tbaa !22 ---snip-- My requirement is for any such LoadInst (example: %5), I want to check if its base GEP (i.e. %3) loads at particular offset (11) from its corresponding

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

We could also simply extend the existing inrange mechanism to non-constantexpr GEPs.  It would remove an inconsistency in the semantics, be relatively straight forward, and solve the motivating example. (I didn't read the proposal in full, so there may be other examples it doesn't solve.) Philip On 7/22/19 10:01 AM, Peter Collingbourne via llvm-dev wrote: > The restrictions of

Hello, We would like to begin discussions around a new set of intrinsics, to better express multi-dimensional array indexing within LLVM. The motivations and a possible design are sketched out below. Rendered RFC link here <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> Raw markdown: # Introducing a new multidimensional array indexing intrinsic ## The

On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > > > > On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev

Hi, In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the only users of bitcast/GEP instruction are lifetime intrinsics (llvm.lifetime.start/end). I did some searching in llvm/test folder, it seems to be true. However, by reading LLVM IR manual, I don't see any restriction stated on the possible user of bitcast/GEP instruction. So my question is who impose the restriction ?

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I’m not sure how transforming GEP offset to i8 type will help alias >> analysis & SROA for the mentioned test case. > > It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent. > Since memory isn't

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

You can run SCEV which will see through bitcasts and GEPs, so it should give an expression of the form (base + offset) on the pointer of the load. Cheers siddharth On Wed 30 May, 2018, 16:30 Venkataramanan Kumar via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > Hi, > > Below is the snippet of LLVM IR code generated by Flang > > ---snip-- > %3 = getelementptr i64,

Hi all, This is covered by (struct-path aware) TBAA, but BasicAA disagrees. See the attached testcase, where it prevents us from removing the redundant load. For arbitrary GEPs, we can't decide based on constant indices (because of e.g., &A[0][1] and &A[1][0], with *A a one-element array). BasicAA has some logic to "try to distinguish something like &A[i][1] against

On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> >> 2016-12-23 22:17 GMT+01:00 David

On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > >> >> >> On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Dec 23, 2016 at 1:01 PM,

----- Original Message ----- > From: "guoqing zhang" <gqzhang81 at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Friday, January 30, 2015 4:29:16 AM > Subject: [LLVMdev] About user of bitcast/GEP instruction > > Hi, > > > In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the > only users of bitcast/GEP instruction are lifetime