search for: memoryoperands

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

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

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, GlobalISel is fantastic, but obviously lacks a lot of the transforms that makes SelectionDAG so good. Whilst it's plenty usable, you'll find yourself wanting/needing to add a lot of manual little transforms to clean things up. I know of the RFC for a new Combiner with its own syntax (https://reviews.llvm.org/D54286 is the latest I can find of it), but after manually adding my Nth

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

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

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jonas Paulsson" <jonas.paulsson at ericsson.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, April 18, 2013 2:33:52 AM > Subject: Re: [LLVMdev] alias analysis in backend > > > On Apr 17, 2013, at 2:33 AM,

Hi As i didn't get any respons I am reformulating my question in the hope to make myself more clear. Has anyone an idea how to use metadata present in the llvm ir to guide the if-conversion in llc (as metadata get's dropped during SelectionDAG) ? -Michael 2013/4/13 Michael D'Hont <michael.dhont at ugent.be> > The project I am working on is to use the llvm toolchain for

...dn’t have an > MachineMemOperand’s, despite being marked as loading from memory. > > Will file a PR so that we can track some of these issues. Coming late to this discussion since I just noticed this was talking about MemRefs... We have deep and horrible problems around our handling of MemoryOperands. As it stands, there does not appear to be a single invariant which is documented and accepted throughout the various backends. There are conflicting assumptions in various bits of code. I tried to clean up some of this a while back and made some forward progress, but there's a lot of wo...

...hineMemOperand’s, despite being marked as loading from memory. >> >> Will file a PR so that we can track some of these issues. > Coming late to this discussion since I just noticed this was talking about MemRefs... > > We have deep and horrible problems around our handling of MemoryOperands. As it stands, there does not appear to be a single invariant which is documented and accepted throughout the various backends. Yeah, i’ve been noticing the same thing :( > There are conflicting assumptions in various bits of code. I tried to clean up some of this a while back and made some f...

The project I am working on is to use the llvm toolchain for embedded CGRA processors . This however poses some restrictions on the block formation, because modulo scheduling is applied in a later stage. For this reason the idea was to create custom pragma's to generate metadata and attach it to de branches of loops we wanted to map on a cgra module. It is a lot similar to the loop parallell

Is this something that will happen in future? Or there is no plan for it? Thanks, Ali -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, April 02, 2008 10:30 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Retrieving local variable names. It's not currently available. LLVM would have to

> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: >> >> FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. > Yeah, I agree. I’ve