search for: pseudosourcevalues

On Monday 14 September 2009 13:07, Dan Gohman wrote: > MachineMemOperands for spill slots use FixedStack PseudoSourceValues > as their base. There's a unique FixedStack PseudoSourceValue for each > fixed frame object, so it's independent of whether frame pointer > elimination has been done, and it's independent of the actual frame > offsets. >From MachineMemOperand.h: /// getValue - Return...

...pping either. With > MachineMemOperands, would that be the getOffset() method? That's > only for FPRel data, though. What if frame pointer elimination has > been run? > > I would love to get out from under the map if possible. MachineMemOperands for spill slots use FixedStack PseudoSourceValues as their base. There's a unique FixedStack PseudoSourceValue for each fixed frame object, so it's independent of whether frame pointer elimination has been done, and it's independent of the actual frame offsets. Dan

On Monday 14 September 2009 12:22, Dan Gohman wrote: > Hi Dave, > > On Sep 11, 2009, at 3:31 PM, David Greene wrote: > > Attached is a patch to print asm comments for spill information. > > We've discussed the mechanisms before but I wanted to run the > > patch by everyone before I start to commit pieces. > > The Offset->FrameIndex mapping seems rather

Here is the warning I am getting: PseudoSourceValue.cpp R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(23) : warning C4156: deletion of an array expression without using the array form of 'delete'; array form substituted R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(72) : see reference to function template instantiation 'void

On Monday 14 September 2009 15:28, David Greene wrote: > I don't see PseudoSourceValue::FPRel, etc. defined anywhere. How do I know > if a PseudoSourceValue is from the stack? Ok, the comment is misleading. I see the class defined in PseudoSourceValue.cpp now. I'll move it to the header. I have another question. Looking at the list of MachineMemOperands for an instruction, is

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a mem

...t preserve the information we > > had from > > Instructions. Codegen might introduce new memory operations after > > lowering > > (spilling, for example). Some of these might be easily analyzable > > (spills) > > but others might not be. > > This is where PseudoSourceValues come in. There are pseudo-values > representing the stack, constants area, GOT, and other memory > locations that aren't represented at the LLVM-IR level. Ok, that's good. But what happens if some codegen pass deletes a memory instruction (or a Value or whatever) and recreates it e...

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following code snippet taken from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04

Hi Duncan, No, it hasn't been reviewed yet. On Mon, May 13, 2013 at 8:50 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, did anything happen with this patch? > > Ciao, Duncan. > > > On 09/05/13 04:04, Akira Hatanaka wrote: > >> The following code snippet taken from StackColoring::**remapInstructions >> clears a >> mem operand if it

Hi, I write again regarding buildSchedGraph(), as I am still not happy about things there. I have found at least two examples which do not work out: 1) SU(2) Store "Value A" SU(1) Store "Value A" SU(0) Load "Value A" If MIsNeedChainEdge() returns false for SU(0) and SU(1), SU(0) is inserted into RejectedMemNodes and removed from its MemUses SU list, as this

Hello All, I just svn update % svn info . Path: . URL: http://llvm.org/svn/llvm-project/llvm/trunk Repository Root: http://llvm.org/svn/llvm-project Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8 Revision: 54012 Node Kind: directory Schedule: normal Last Changed Author: wangmp Last Changed Rev: 54007 Last Changed Date: 2008-07-25 03:30:26 +0200 (Fri, 25 Jul 2008) make[3]: Entering

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

Disclaimer: I haven’t been following this discussion closely, nor do I know what is going on in the modern AA/MemorySSA/GVN infra, but: I’d prefer to avoid abusing the Value* class hierarchy if reasonable. Adding new subclasses that only occur in special cases makes it more difficult to reason about what can occur and when. A historical example that always grated against my sensibilities was

On Fri, Dec 5, 2008 at 1:58 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >>> / * snip */ >> >> Actually, rebuilding it makes "debug tblgen" fail with the errors at >> the

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

...think it's sufficient to just preserve the information we > had from > Instructions. Codegen might introduce new memory operations after > lowering > (spilling, for example). Some of these might be easily analyzable > (spills) > but others might not be. This is where PseudoSourceValues come in. There are pseudo-values representing the stack, constants area, GOT, and other memory locations that aren't represented at the LLVM-IR level. > > > But maybe we don't need to worry about that right now. As I think > about the > problem I'm working on, "m...

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