similar to: [LLVMdev] Machine-level Memory Dependence

Back in August, several of us participated in a discussion about getting a more robust memory dependence analysis framework into LLVM. Wojtek Matyjewicz has done some work on this and he attached a patch to an e-mail at the time that built against an older version of LLVM. Wojtek, what's the status of this patch? Does it build against HEAD? Do you plan to check it in any time soon?

On Jan 19, 2009, at 5:06 PM, David Greene wrote: > On Monday 19 January 2009 18:21, Dan Gohman wrote: > >>> Dan, how does the scheduler handle memory dependence? I'm working >>> on >>> something that requires memory dependence information for >>> MachineInstructions. >> >> At the moment, it knows simple things, like constant pool loads

On Monday 19 January 2009 19:47, Dan Gohman wrote: > > Can they be used in conjunction with > > MemoryDependenceAnalysis? e.g. can we write a MachineInstructions- > > based > > memory dependence analysis that uses MachineMemoryOperands? > > Right, the existing MemoryDependenceAnalysis works in terms of > LLVM-IR-level Instructions, but yes, it would be possible

On Monday 19 January 2009 18:21, Dan Gohman wrote: > > Dan, how does the scheduler handle memory dependence? I'm working on > > something that requires memory dependence information for > > MachineInstructions. > > At the moment, it knows simple things, like constant pool loads > don't have dependencies, and references to distinct stack slots are >

Andrew Lenharth wrote: > On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote: >> - No varargs > > What are your issues here? Or are they simply at the "not implemented > so I don't know" stage? The two bugs I mentioned (no varargs, no alloca) are pretty much two sides of the same coin: I'm ignoring the IA64 stack frame layout (for no good reason), so

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

On Fri, 18 Mar 2005, Duraid Madina wrote: >>> - No instruction scheduling/bundling of any sort >> >> So this one needs to be coordinated. Next week, I might see about >> adding MachineInstruction support to the SelectionDAG so you can load up >> a DAG post-ISel and then spit it back out scheduled. > > That would be much appreciated, particularly if it

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 Jan 19, 2009, at 3:38 PM, David Greene wrote: > On Monday 19 January 2009 16:42, Dan Gohman wrote: > >>>> Perhaps you want to do this after register allocation is done. >>>> Dan is >>>> developing the post-allocation scheduler. You can try it out. >>> >>> Interesting. Can it already be found SVN? I will search the mail >>>

Hi,   I want to list some additional information on this.   The variable collection I am looking at is, "variables 'declared' in scope".   1. When I traverse the MachineInstructions in the LexicalScopes ranges, and check for variables, I get variables used in this scope.      The variables listed include variables which may not have been declared in the scope. (for example

--lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Collin Starkweather <collin.starkweather@color= ado.edu> ----- --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Collin Starkweather http://www.collinstarkweather.com Consulting Software

On Monday 19 January 2009 16:42, Dan Gohman wrote: > >> Perhaps you want to do this after register allocation is done. Dan is > >> developing the post-allocation scheduler. You can try it out. > > > > Interesting. Can it already be found SVN? I will search the mail > > archive > > later, if not. > > Yes, it is in SVN. It's new, and so far

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

On Thu, 2005-03-17 at 23:31 -0600, Chris Lattner wrote: > On Fri, 18 Mar 2005, Duraid Madina wrote: > >>> - No instruction scheduling/bundling of any sort > >> > >> So this one needs to be coordinated. Next week, I might see about > >> adding MachineInstruction support to the SelectionDAG so you can load up > >> a DAG post-ISel and then spit it

Hi, I am trying to do dependence analysis (loop dependences) on machine code. But, scalar evolution doesn't work as expected (like at IR level - opt pass). I am not getting enough clue as to how to proceed.. One naive way of getting the dependence information can be - Do dependence analysis at IR level and attach the information as meta data. And then use this information at machine code

The InlineSpiller in 3.1 is quite different from the old spiller so I am trying to slog through the code and learn a bit. On a spill, the spiller calls traceSiblingValue. I gather that this is supposed to find the "original" def point of a value, checking back through copies, phis, etc. At the end we have an interval being spilled and the original def instruction of the value. For

On Mar 15, 2013, at 3:18 AM, rahul <rahul3527 at gmail.com> wrote: > > Hi, > > I am trying to do dependence analysis (loop dependences) on machine code. > But, scalar evolution doesn't work as expected (like at IR level - opt pass). > I am not getting enough clue as to how to proceed.. > > One naive way of getting the dependence information can be > - Do

On 8/7/07, David Greene <dag at cray.com> wrote: > > On Monday 06 August 2007 12:15, Anton Vayvod wrote: > > > Spill intervals must be precolored because they can't be spilled once > more. > > They are the shortest intervals precisely over each def/use of the > original > > interval. That is why they also have their weights set to #INF. > > Yes,

On Sep 5, 2005, at 10:21 AM, Andrew Lenharth wrote: > On Mon, 2005-09-05 at 14:45 +0800, Tzu-Chien Chiu wrote: > >> why there is no general dependency analysis for the "machin code"? >> perhaps it's because the instruction scheduling is only implemented >> for sparcv9? >> > > Most backends use the SelectionDAG infastructure to do this kind of >

On Sep 19, 2012, at 10:13 AM, dag at cray.com wrote: > The InlineSpiller in 3.1 is quite different from the old spiller so I am > trying to slog through the code and learn a bit. > > On a spill, the spiller calls traceSiblingValue. I gather that this is > supposed to find the "original" def point of a value, checking back > through copies, phis, etc. At the end we