search for: svoffset

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 place that passed through...

...> with > > a default argument helping to hide it. > > Can you be more specific about what the bugs are? Sure. SelectionDAG::getStore and getLoad are declared like this: SDOperand getLoad(MVT::ValueType VT, SDOperand Chain, SDOperand Ptr, const Value *SV, int SVOffset, bool isVolatile=false); SDOperand getStore(SDOperand Chain, SDOperand Val, SDOperand Ptr, const Value *SV, int SVOffset, bool isVolatile=false); In SelectionDAGISel.cpp in SelectionDAGLowering::getLoadFrom and SelectionDAGLowering::visitStore they are called like this:...

...em; it understands integer arithmetic and PHIs quite well, but doesn't currently understand GEPs. I know it can be made to understand GEPs though, and it's on my TODO list to implement this. * 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. * The DAGCombiner's alias-analysis handling isn't ideal. This is the -c...

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

Hi, > My initial reaction is that if one were to decorate MachineInstr's > with the LLVM level pointer values that they use for reading > and writing memory, this is already the case: SrcValue and SVOffset. Ciao, Duncan.

...you added a new node kind, TargetSrcValue, instead of just using the existing SRCVALUE. > + else if (MRO.SrcValue && !MRO.SrcValue->getName().empty()) > + OS << "[" << MRO.SrcValue->getName() << "]"; This code should also print the SVOffset value. > + SDOperand getVecLoad(unsigned Count, MVT::ValueType VT, SDOperand Chain, > + SDOperand Ptr, SDOperand SV); This is code that was deleted from the LLVM trunk recently; it looks like it shouldn't be included in this patch. Dan -- Dan Gohman, Cray Inc.

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 Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...e a set of - /// loads to load a vector with a resulting wider type. It takes - /// LdChain: list of chains for the load we have generated - /// Chain: incoming chain for the ld vector - /// BasePtr: base pointer to load from - /// SV: memory disambiguation source value - /// SVOffset: memory disambiugation offset - /// Alignment: alignment of the memory - /// isVolatile: volatile load - /// LdWidth: width of memory that we want to load - /// ResType: the wider result result type for the resulting loaded vector - SDValue genWidenVectorLoads(SDValueVector&...

...s is actually done, but anyway i wanted to be on the safe side. > >> + else if (MRO.SrcValue && !MRO.SrcValue->getName().empty()) >> + OS << "[" << MRO.SrcValue->getName() << "]"; > > This code should also print the SVOffset value. this was meant for debugging purpose only, but yes it would be helpful to print the offset. this leads to a question on how to query the alias analysis. when i have a look at the alias set tracker, it seems that only the value and the size of the type is relevant for the query. but when i...

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

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

Hello, I'm trying to understand SelectionDAG::getLoad() and the relation between the pointer and MachineMemOp. What does the MachineMemOp do in the getLoad()? Why is both pointer (parameters SDValue Ptr, SDValue Offset) and the MMO (parameters const Value *SV, int SVOffset) needed? And the Alignment parameter seems to be the alignment of the SV without the Offset, aswell as the generated LOAD node? Can Ptr and SV point to different places? What happens in that case? (and what obvious question did I not ask here?) thank you in advance, kalle

Duncan Sands wrote: >> My initial reaction is that if one were to decorate MachineInstr's >> with the LLVM level pointer values that they use for reading >> and writing memory, > > this is already the case: SrcValue and SVOffset. Ah, that's right. I went back and read the discussion from January, and Florian Brandner explains there that the real culprit is the lowering of GEP in the codegen prepare pass. Florian, if you have worked more on this, we would be very interested in your work. Serialization caused by memory...

...viously not always the case, but it is VERY VERY VERY often the case, so we should see how far that gets us. If nothing else, it makes the IR sent into the codegen simpler and smaller. > * 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. This is also a serious issue that can manifest as bugs a...

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