search for: pseudosourcevalu

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

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

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

...operand since we don't know for sure that it doesn't 537 // alias a merged alloca. 538 MMO->setValue(0); 539 continue; 540 } The attached patch makes the code above less conservative. It avoids clearing a mem operand if its underlying value is a PseudoSourceValue and PseudoSourceValue::isConstant returns true. This enables MachineLICM to hoist loads from GOT out of a loop (see test case in stackcoloring-test.patch). Please review. Question: Why does it need to clear a mem operand if the underlying object is not an AllocaInst? I am not sure if I understan...

...operand since we don't know for sure that it doesn't 537 // alias a merged alloca. 538 MMO->setValue(0); 539 continue; 540 } The attached patch makes the code above less conservative. It avoids clearing a mem operand if its underlying value is a PseudoSourceValue and PseudoSourceValue::isConstant returns true. This enables MachineLICM to hoist loads from GOT out of a loop (see test case in stackcoloring-test.patch). Please review. Question: Why does it need to clear a mem operand if the underlying object is not an AllocaInst? I am not sure if I understan...

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

...re that it doesn't > 537 // alias a merged alloca. > 538 MMO->setValue(0); > 539 continue; > 540 } > > The attached patch makes the code above less conservative. It avoids clearing a > mem operand if its underlying value is a PseudoSourceValue and > PseudoSourceValue::isConstant returns true. This enables MachineLICM to hoist > loads from GOT out of a loop (see test case in stackcoloring-test.patch). > > Please review. > > Question: Why does it need to clear a mem operand if the underlying object is > not an AllocaI...

...w for sure that it doesn't > 537 // alias a merged alloca. > 538 MMO->setValue(0); > 539 continue; > 540 } > > The attached patch makes the code above less conservative. It avoids clearing a mem operand if its underlying value is a PseudoSourceValue and PseudoSourceValue::isConstant returns true. This enables MachineLICM to hoist loads from GOT out of a loop (see test case in stackcoloring-test.patch). > > Please review. > > Question: Why does it need to clear a mem operand if the underlying object is not an AllocaInst? I am not...

...// alias a merged alloca. >> 538 MMO->setValue(0); >> 539 continue; >> 540 } >> >> The attached patch makes the code above less conservative. It avoids >> clearing a >> mem operand if its underlying value is a PseudoSourceValue and >> PseudoSourceValue::isConstant returns true. This enables MachineLICM to >> hoist >> loads from GOT out of a loop (see test case in stackcoloring-test.patch). >> >> Please review. >> >> Question: Why does it need to clear a mem operand if the underly...

...e recursively with successors? If this is a latency issue, perhaps it would be ok to do "continue" after adding the pred if the latency is non-zero? Right now this seems to be always zero, or one in the store-load case per the comment on line 856. On line 947: "A store to a specific PseudoSourceValue" should probably say "... a specific Value / PseudoSourceValue", right? The same goes for line 1029. /Jonas

...g/llvm/lib/Transforms/Hello' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/src/Lang/llvm/lib/Transforms/Hello' make[2]: Leaving directory `/usr/src/Lang/llvm/lib/Transforms' make[2]: Entering directory `/usr/src/Lang/llvm/lib/CodeGen' llvm[2]: Compiling PseudoSourceValue.cpp for Debug build In file included from PseudoSourceValue.cpp:14: /usr/src/Lang/llvm/include/llvm/CodeGen/MachineFrameInfo.h:86: error: 'uint64_t' does not name a type /usr/src/Lang/llvm/include/llvm/CodeGen/MachineFrameInfo.h:98: error: 'int64_t' does not name a type /usr/src/...

...sChainEdge() return false in this > case. > > > > What should I do? Adding a MemoryOperand to such an instruction seems > right, but it doesn’t seem to fit quite. What Value would be > referenced? I think that they should have pseudo-source values, see: include/llvm/CodeGen/PseudoSourceValue.h I was under the impression that different pseudo source values from different frame indices already have this no-alias property. If they don't, then this seems like a nice general improvement that would benefit all backends. -Hal > BasicAliasAnalysis returns MustAlias for the same Val...

...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 CodeGen/PseudoSourceValue, which originally inherited from Value in order to make it “fit better” into the AA infra. Thankfully Nick Lewycky broke that tie back in a patch on Tue Apr 15 07:22:52 2014, and the codebase has been better off for that change. All this is to say that I’d prefer to avoid tying it into Value jus...

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

...gt; > > > > > > > What should I do? Adding a MemoryOperand to such an instruction seems > > right, but it doesn't seem to fit quite. What Value would be > > referenced? > > I think that they should have pseudo-source values, see: > include/llvm/CodeGen/PseudoSourceValue.h > > I was under the impression that different pseudo source values from > different frame indices already have this no-alias property. If they > don't, then this seems like a nice general improvement that would benefit > all backends. > > -Hal > > > BasicAli...

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, &quot...

...? Adding a MemoryOperand to such an instruction >>>> seems >>>> right, but it doesn't seem to fit quite. What Value would be >>>> referenced? >>> >>> I think that they should have pseudo-source values, see: >>> include/llvm/CodeGen/PseudoSourceValue.h >>> >>> I was under the impression that different pseudo source values from >>> different frame indices already have this no-alias property. If >>> they >>> don't, then this seems like a nice general improvement that would >>> benefit &g...