similar to: [LLVMdev] alias information in codegen

On Apr 3, 2008, at 1:00 PM, Dan Gohman wrote: > * BasicAliasAnalysis, the default AliasAnalysis implementation, > doesn't > understand lowered GEPs, integer arithmetic, or PHIs, and the > regular codegen process involves passes that lower GEPs. Sure. > One way to solve this is to use a different AliasAnalysis > implementation. > I haven't looked at it in

On Thu, April 3, 2008 7:33 pm, Chris Lattner wrote: > On Apr 3, 2008, at 1:00 PM, Dan Gohman wrote: >> * BasicAliasAnalysis, the default AliasAnalysis implementation, >> doesn't >> understand lowered GEPs, integer arithmetic, or PHIs, and the >> regular codegen process involves passes that lower GEPs. > > Sure. > >> One way to solve this is to use

Hi, > * There are still a variety of places in SelectionDAG creation that > don't preserve SVOperand/SVOffset (as well as alignment and > volatile). > > These places need to be found and fixed. This is pretty straight- > forward, > and the places that need changing can be found by inserting some > strategic assert(SVOperand)'s. I've seen at least one

Dan Gohman wrote: > I tried out your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction

On Thu, Apr 3, 2008 at 10:33 PM, Chris Lattner <sabre at nondot.org> wrote: > On Apr 3, 2008, at 1:00 PM, Dan Gohman wrote: > > * BasicAliasAnalysis, the default AliasAnalysis implementation, > > doesn't > > understand lowered GEPs, integer arithmetic, or PHIs, and the > > regular codegen process involves passes that lower GEPs. > > Sure. >

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

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 Dec 19, 2006, at 12:13 PM, Dan Gohman wrote: > Hello, > > I did a little experiment modifying LLVM to be able to use alias- > analysis > information in scheduling so that independent memory operations may be > reordered. I am not sure if it is a good idea to do this at scheduling time. LLVM explicitly models control flows dependencies as chain operands. This eliminated

I am pretty excited about the recent activity on dependence analysis. The only remaining problem from our point of view is how to get the alias information to the back end instruction scheduler. If I understand things correctly, the alias information basically gets lost in the process of lowering to target instructions. We are interested in the DSP domain, so we really need to get SIMD style

On Thu, Jan 15, 2015 at 1:26 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 15 January 2015 at 13:10, Daniel Berlin <dberlin at dberlin.org> wrote: > >> Yes. >> I've attached an updated patch that does the following: >> >> 1. Fixes the partialalias of globals/arguments >> 2. Enables partialalias for cases where nothing has been unified to

Hi Hal, Thanks. How about a symbol with two different immediate offsets - the Value* would be the same, right? I don't see how AliasAnalysis::Location would handle this... And BasicAliasAnalysis does if (V1 == V2) return MustAlias; , so I'm not sure how this would be done .. ? /Jonas > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent:

Hi, I would like to implement alias analysis in my backend. I would like to for example get the result that two stack-accesses with different offsets (indexes), would return noAlias. However, I'm somewhat confused as there is no notion of offset for the Location object. I would also like to call ScheduleDAGInstr::buildSchedGraph() with this AliasAnalysis and have MIsNeedsChainEdge() return

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

On Apr 17, 2013, at 2:33 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 12:22:49 AM >> Subject: RE: [LLVMdev] alias analysis in backend

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger > > The original issue is that clang maps restrict on function arguments to > > NoAlias and that makes compares against the address of global variables > > false. Minimal test case: > > > > @y = external global i32 > > > > define zeroext i1

On Thursday 03 April 2008 22:00:34 Dan Gohman wrote: > However, for people just interested in post-regalloc scheduling and > VLIW packing and similar things, MemOperands aren't the only approach. > A potentially better way to do this would be to extend MachineInstrs > to preserve the chain dependencies from the SelectionDAG. the selection dag may already contain unnecessary

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, April 17, 2013 12:22:49 AM > Subject: RE: [LLVMdev] alias analysis in backend > > Hi Hal, > > Thanks. How about a symbol with two different immediate offsets - the

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >

This is the first patch I've sent to this project. Please be gentle :) LLVM fails to remove the dead load in the following code when running $./llvm-as -o - test.ll | ./opt -O3 -o - | ./llvm-dis -o - %t = type { i32 } declare void @foo(i8*) define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 %before = load i32* %p call void

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, April 16, 2013 11:24:36 AM > Subject: [LLVMdev] alias analysis in backend > > > > > > Hi, > > > > I would like to implement alias analysis in my backend. I would like > to for example get the result