similar to: What is HexagonCommonGEP.cpp for?

Sounds like you break a single getelementptr into a few smaller ones, then do CSE-like optimization? 2017-06-14 21:11 GMT+08:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > On 6/14/2017 7:44 AM, 陳韋任 via llvm-dev wrote: > >> >> Skim through Hexagon backend, I notice there is HexagonCommonGEP.cpp >> which seems >> try to do something on

Krzystof, Is this partly due to hardware loops not being common? I'm curious, we do something very similar for similar reasons. On Wed, Jun 14, 2017 at 10:23 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 6/14/2017 9:05 AM, 陳韋任 wrote: > >> I only see Hexagon has such optimization, is there any reason that >> Hexagon need this?

I only see Hexagon has such optimization, is there any reason that Hexagon need this? No existing optimization does similar thing? Thanks, Regards, chenwj 2017-06-14 21:51 GMT+08:00 Krzysztof Parzyszek <kparzysz at codeaurora.org>: > On 6/14/2017 8:16 AM, 陳韋任 wrote: > >> Sounds like you break a single getelementptr into a few smaller ones, >> then do CSE-like

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

I understand that GEPs do not access memory. They do a (possibly expensive) address calculation, perhaps adding a few values to a label and leaving the result in a register. Getting a label into a register is (to me) just like loading a 64-bit integer value into a register. It can happen in many places and it can cost a few instructions and several bytes. I'd like to see such things commoned

Originally on llvm-commits. On May 30, 2012, at 8:48 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> This is probably fine for now. It's a relatively safe use of SCEVExpander and the least effort approach, but generally I would like to encourage people to solve local rewrite problems with IRBuilder, not SCEVExpander, and build useful utilities for that purpose. Just because you

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

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

A GEP can represent a potentially large tree of instructions. Seems like all the sub-trees are hidden from optimization; that is, I never see licm or value numbering doing anything with them. If I rewrite the GEPs as lots of little adds and multiplies, then opt will do a better job (I speculate this happens during lowering). One of the computations that's hidden in the GEP in my example is

Hi, We wrote an optimization that eliminates common sub-expressions in a group of similar GEPs for the NVPTX backend. It speeds up some of our benchmarks by up to 20%, which convinces us to try to upstream it. Here's a brief description of why we wrote this optimization, what we did, and how we did it. Loops in CUDA programs are often extensively unrolled by programmers and compilers,

Hi Hal, Thanks for your comments! I'm inlining my responses below. Jingyue On Sat, Apr 19, 2014 at 6:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Jingyue, > > I can't speak for the NVPTX backend, but I think this looks useful as an > (optional) target-independent pass. A few thoughts: > > - Running GVN tends to be pretty expensive; have you tried EarlyCSE

----- Original Message ----- > From: "Jingyue Wu" <jingyue at google.com> > To: "Daniel Berlin" <dberlin at dberlin.org>, "Mark Heffernan" <meheff at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 13, 2015 1:31:59 PM >

Hi, I've been wondering why LLVMs GEP instructions are based on types, rather than encoding the raw address calculation as a base pointer plus some scaled offsets (still in the form of a GEP, to retain provenance). The type information does not seem particularly useful (shouldn't be used as an optimization base, because struct layouts lie), but increases the non-canonical IR space (there

On Mon, Feb 23, 2015 at 2:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Francois Pichet" <pichet2000 at gmail.com> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Sunday, February 22, 2015 5:34:11 PM > > Subject: [LLVMdev] Question about shouldMergeGEPs in

BTW are we planning to also remove gep 0 after we would have typeless pointers? I saw the David's presentation year ago but I am not sure if it was mentioned. If it would be removed, then does it mean that SROA would still need some new code to handle it (assuming it doesn't handle bitcasts right now) Here is the patch solving my issue https://reviews.llvm.org/D28126 2016-12-25 13:40

On Fri, Mar 13, 2015 at 10:16 AM Mark Heffernan <meheff at google.com> wrote: > On Thu, Mar 12, 2015 at 2:34 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> It is not clear to me at all that preventing the merging is the right >> solution. There are a large number of analysis, including alias analysis, >> and optimizations that use GetUnderlyingObject, and

2016-12-24 9:39 GMT+01:00 Chandler Carruth <chandlerc at google.com>: > On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > > 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 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 Mon, Feb 2, 2015 at 10:59 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Feb 2, 2015 at 10:55 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: > >> Ah yes, the structs are what make it messy. >> >> How about the more useful constraint: >> - the (identical) base must point to a (possibly multidimensional) array >>

Am Mo., 22. Juli 2019 um 10:50 Uhr schrieb Doerfert, Johannes <jdoerfert at anl.gov>: > Why introduce a new intrinsic (family)? It seems that would require us > to support GEPs and GEP + "multi-dim" semantics in various places. What is > the benefit over a GEP extension? Adding an intrinsic is easier than adding or extending an existing instruction, as suggested by