similar to: [LLVMdev] Alias analysis and instruction level parallelism

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.

On Apr 2, 2008, at 1:14 AM, Pertti Kellomäki wrote: > 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 >

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

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.

On Mon, Jul 23, 2007 at 02:19:38PM +0200, Florian Brandner wrote: > hi, > > i know it took a while, but here is a patch that adds a list of source > values to machine instructions. Cool! > i've testet all this for our backend only, which is not public. i do not > know how much has to be done to integrate this with the other, e.g., the > x86, targets. does any of the

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

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

Florian Brandner wrote: > an other option would be to save the GEP instructions and provide a mapping > between them and the lowered arithmetic. it's not very clean but it would be > safe, and probably work well. In my opinion this seems like the obvious way to go. The information is already there, so reverse engineering it back does not sound too clever. Of course if the reverse

Dan Gohman wrote: > I think this is trickier than it sounds; the reason GEPs are lowered > is to > allow strength-reduction and other things to do transformations on them. > It would require those passes to know how to update the mapping. Yes, I do appreciate the amount of work involved, and I am very open to other suggestions. What the backend really needs to know is what loads

On Wednesday 02 April 2008 11:54:26 Pertti Kellomäki wrote: > 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. codgenprepare rewrites GEP instructions into a sequence of PtrToInt casts, additions, multiplies and finally a IntToPtr cast. The basic alias

On Apr 3, 2008, at 12:31 AM, Pertti Kellomäki wrote: > Florian Brandner wrote: >> an other option would be to save the GEP instructions and provide a >> mapping >> between them and the lowered arithmetic. it's not very clean but it >> would be >> safe, and probably work well. > > In my opinion this seems like the obvious way to go. I think this is

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

There have been a few queries about this recently, and I've done some work in this area recently, so I'm posting a summary of what the major outstanding issues are. * BasicAliasAnalysis, the default AliasAnalysis implementation, doesn't understand lowered GEPs, integer arithmetic, or PHIs, and the regular codegen process involves passes that lower GEPs. One way to solve this is

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

On Tue, Dec 19, 2006 at 01:31:10PM -0800, Evan Cheng wrote: > > 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

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

We are using LLVM to target a customizable processor architecture. One of the activities to be supported is architecture exploration, where one explores the processor design space (e.g. connectivity, number of FUs) and tries to find a good match for the application at hand. The exploration needs to be relatively rapid, so targeting and compiling gcc for each of the processor variants is not

Ralf Schneider wrote: > A little bit off topic: Has anybody tried building a concurrent GC - > running in a different _process_, instead of a thread? > The idea: To perform a collection you do a fork(). The child process > collects all unreferenced memory regions and reports them back to the > parent process. I remember reading a paper in ACM Sigplan Notices (I think) many years

hi, i am building selectionDAG by my own code, but got a assertion fail said "SrcValue is not a pointer?". but since the comment above the SrcValueSDNode said: "SrcValueSDNode - An SDNode that holds an arbitrary LLVM IR Value." why the llvm value of SrcValueSDNode must be with PointerType? is that assertion necessary? thanks a lots. regards --ether

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode