similar to: [LLVMdev] SCEV Question

On Sep 9, 2010, at 1:48 PM, David Greene wrote: > LLVM 2.7's ScalarEvolution.cpp has this scary comment: > > // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can > // lead to pointer expressions which cannot safely be expanded to GEPs, > // because ScalarEvolution doesn't respect the GEP aliasing rules when > // simplifying integer

I have a few enhancements to SCEV to help it identify more types of recurrences. I want to send these upstream but I need a little feedback. I've added ptrtoint and inttoptr SCEV expressions so that recurrences involving these constructs can be recognized. However, this scary comment gives me pause: // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can //

Hello all, There is a missing vectorization opportunity issue with clang 4.0 with the file attached. Indeed, when compiled with -O2, the "op_distance" function get vectorized, but not the "op" one. For information, this test case has been reduced from a file generated by the Pythran compiler (https://github.com/serge-sans-paille/pythran). If we take a look at the generated

On Feb 23, 2012, at 8:20 AM, David Greene wrote: > I have a few enhancements to SCEV to help it identify more types of > recurrences. I want to send these upstream but I need a little > feedback. > > I've added ptrtoint and inttoptr SCEV expressions so that recurrences > involving these constructs can be recognized. However, this scary > comment gives me pause: >

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

Dan Gohman <gohman at apple.com> writes: >> These enhancements are critical for us because of the way our frontends >> work (less than ideal but we have to deal with it), due to some language >> quirks (casting in C, odd Fortran constructs, etc.) and because users >> sometimes stretch the boundaries of good taste :). >> >> Is this a reasonable approach?

Hi again, So I finally gave up on trying to get through the converting (x86' push pop mov add) because it deals a lot with crazy pointer arithmetics and sonce inttoptr and ptrtoint doesn't provide any alias analysis information. Daniel, you said it doesn't make much sense to provide it but in my cases it is actually very much needed, you didn't say it wasn't possible to

Hello, I'm working on refining the definition of getelementptr (GEP) to clarify its semantics and to allow front-ends to provide additional information to optimization passes. To help support this, I'd like to propose the following rule: Any memory access must be done though a pointer value associated with with address range of the memory access, otherwise the behavior is undefined.

On Jul 22, 2009, at 1:30 PM, Dan Gohman wrote: > Hello, > > I'm working on refining the definition of getelementptr (GEP) to > clarify its semantics and to allow front-ends to provide additional > information to optimization passes. It would be quite valuable to have cleaner semantics for GEPs, both for LLVM in general and for the memory safety work we have been doing in

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

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 Feb 24, 2012, at 9:53 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >>> These enhancements are critical for us because of the way our frontends >>> work (less than ideal but we have to deal with it), due to some language >>> quirks (casting in C, odd Fortran constructs, etc.) and because users >>> sometimes stretch the

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

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

Hi, I noticed an inconsistency in how ScalarEvolution orders instruction operands. This inconsistency can result in creation of separate (%a * %b) and (%b * %a) SCEVs as demonstrated by the example IR below (attached as gep-phi.ll)- target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" define void @foo(i8* nocapture %arr, i32 %n, i32* %A, i32* %B) local_unnamed_addr {

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

When multiple GEPs or other operations are used for the address calculation, OptimizeMemoryInst() performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so that ISel could have better chance to fold address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this transformation

----- 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 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: > > > When multiple GEPs or other operations are used for the address calculation, OptimizeMemoryInst() performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so that ISel could have better chance to fold address