On Jun 12, 2007, at 10:53 AM, Chris Lattner wrote:> On Tue, 12 Jun 2007, Christopher Lamb wrote: >>>> What's the best way to get an SDNode through to DAG scheduling >>>> without getting mangled during Lowering/ISel? >>> >>> What do you mean by "mangled"? Please clarify. >> >> My mangled I mean the nodes shouldn't be isel'ed into anything >> else because >> they need to survive through to scheduling. Is there a preferred >> means of >> having those nodes skipped during selection and lowering? > > You'll have to teach legalize and isel about these nodes, just like > they > know about ISD::Register nodes. subregs will be a new first-class > node > type that all of the dag stuff will have to know about (at least to > pass > them through).Great! Found the spot to do that.> >>>> When should subregs be flattened to actual registers: AsmPrinter? >>>> Somewhere in LiveIntervals, during RegAlloc? > > This should definitely be done during regalloc.It seems that LiveIntervals will need to be taught about the new form of virtual registers. Hrm. I'm going to try to break this work up as much as possible. Also, do you see any problems with using the following class for vregs? It makes it possible to not have to go through and update every call site for a large number of functions. class vreg : public std::pair<unsigned,unsigned> { public: vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} }; If this definition is OK, where should it live? It's needed all over the place... -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070612/5f81b159/attachment.html>
On Jun 13, 2007, at 10:50 AM, Chris Lattner wrote:> On Tue, 12 Jun 2007, Christopher Lamb wrote: >>>>>> When should subregs be flattened to actual registers: >>>>>> AsmPrinter? >>>>>> Somewhere in LiveIntervals, during RegAlloc? >>> >>> This should definitely be done during regalloc. >> >> It seems that LiveIntervals will need to be taught about the new >> form of >> virtual registers. Hrm. I'm going to try to break this work up as >> much as >> possible. > > Splitting up the work is good :) > >> Also, do you see any problems with using the following class for >> vregs? It >> makes it possible to not have to go through and update every call >> site for a >> large number of functions. >> >> class vreg : public std::pair<unsigned,unsigned> { >> public: >> vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} >> }; >> >> If this definition is OK, where should it live? It's needed all >> over the >> place... > > Where would you use this? It seems that the only place that would > need it > is in the DAG schedulers, which turn the dags into a machineinstr > stream. > If so, putting it into the scheduler baseclass would make sense.It gets used in MachineInstrBuilder, MachineInstr, MRegisterInfo, and ScheduleDAG. Basically any place where a vreg currently gets passed around by an unsigned needs to accept the pair. In my working copy I've split it out into it's own header file to reduce extraneous includes.> If you do something like this, I'd suggest a trivial value class that > doesn't derive from std::pair.By a value class do you mean a subclass of Value or just a class with no superclass? -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070613/fd30fddc/attachment.html>
On Tue, 12 Jun 2007, Christopher Lamb wrote:>> > > > When should subregs be flattened to actual registers: AsmPrinter? >> > > > Somewhere in LiveIntervals, during RegAlloc? >> >> This should definitely be done during regalloc. > > It seems that LiveIntervals will need to be taught about the new form of > virtual registers. Hrm. I'm going to try to break this work up as much as > possible.Splitting up the work is good :)> Also, do you see any problems with using the following class for vregs? It > makes it possible to not have to go through and update every call site for a > large number of functions. > > class vreg : public std::pair<unsigned,unsigned> { > public: > vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} > }; > > If this definition is OK, where should it live? It's needed all over the > place...Where would you use this? It seems that the only place that would need it is in the DAG schedulers, which turn the dags into a machineinstr stream. If so, putting it into the scheduler baseclass would make sense. If you do something like this, I'd suggest a trivial value class that doesn't derive from std::pair. -Chris -- http://nondot.org/sabre/ http://llvm.org/