similar to: [LLVMdev] RFC: GEP as canonical form for pointer addressing

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

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

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

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

On Nov 21, 2013, at 10:37 PM, Andrew Trick <atrick at apple.com> wrote: > > 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>

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 5 February 2014 09:45, Philip Reames <listmail at philipreames.com> wrote: > On 1/31/14 5:23 PM, Nick Lewycky wrote: > > On 30 January 2014 09:55, Philip Reames <listmail at philipreames.com> wrote: > >> On 1/29/14 3:40 PM, Nick Lewycky wrote: >> >>> The LLVM Module has an optional target triple and target datalayout. >>> Without them, an

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

I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. Thanks, Jun On Nov 12, 2013, at 12:07 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The reason for this is to allow folding of address computation into loads and stores. A lot of modern arch, e.g. X86 and arm,

On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: > > I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. I believe it's primary for address mode matching where only part of the GEP can be folded (depending on the instruction set). Evan

Hi All, In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by converting GET to integers? It appear that it have impacts on ISel's result, but I'm not clear about the main purpose of the transformation. FROM : for.body.lr.ph: %zzz = getelementptr inbounds %struct.SS* %a2, i32 0, i32 35 for.body: %4 =

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s

On 20 Feb 2014, at 06:11, Ivan Godard <ivan at ootbcomp.com> wrote: > It's not just old mainframes, it's some of the newest architecture as well. > The Mill general-purpose architecture (http://ootbcomp.com) has non-integer > pointers and distinct pointer operations too. That LLVM loses pointerhood is > the biggest problem that we have identified while looking into using

The reason for this is to allow folding of address computation into loads and stores. A lot of modern arch, e.g. X86 and arm, have complex addressing mode. Evan Sent from my iPad > On Nov 12, 2013, at 8:39 AM, Junbum Lim <junbums at gmail.com> wrote: > > Hi All, > > In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by

On Fri, Jun 15, 2007 at 04:16:57PM +0200, Florian Brandner wrote: > hi, > > > Florian Brandner wrote: > > Dan Gohman wrote: > >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: > >>> Right. The original Value*'s are preserved in the DAG, but dropped when > >>> MachineInstrs are created. We could add a machineoperand to

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 expressions. I think I understand what the comment is saying. If a GEP has

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