Thanks for the detailed response. On Apr 23, 2007, at 4:22 PM, Chris Lattner wrote:> Right. Evan is currently focusing on getting the late stages of > the code > generator (e.g. livevars) to be able to understand arbitrary machine > instrs in the face of physreg subregs. This lays the groundwork for > handling vreg subregs, but won't solve it directly.Is the work Evan doing a prerequisite for supporting vreg subregs? Is there a PR for the feature Evan is working on?>> Is any of this kind of work planned? The addition of those >> MRegisterInfo functions has me curious... > > This is on our mid-term plan, which means we'll probably tackle it > over > the next year or so, but we don't have any concrete plans in the > immediate > future. If you are interested, this should be a pretty reasonable > project > that will give you a chance to become more familiar with various > pieces of > the early code generator. :)I have other higher priority tasks right now, but I think we'll want to have this in sooner rather than later. If you have any pointers on a good starting point it'd be mighty helpful. If I can get a grasp on it I'll start incremental work in the background. Probably the place to start would be opening a PR. Does "Support for vreg subregs" capture the essence of the enhancement? -- Christopher Lamb
On Apr 23, 2007, at 4:07 PM, Christopher Lamb wrote:> Thanks for the detailed response. > > On Apr 23, 2007, at 4:22 PM, Chris Lattner wrote: > >> Right. Evan is currently focusing on getting the late stages of >> the code >> generator (e.g. livevars) to be able to understand arbitrary machine >> instrs in the face of physreg subregs. This lays the groundwork for >> handling vreg subregs, but won't solve it directly. > > Is the work Evan doing a prerequisite for supporting vreg subregs?Sort of. vreg subregs work can start before I finish phyregs subregs support. But unless there are no live-in registers nothing can possibly work.> Is there a PR for the feature Evan is working on?You filed it. PR1306. :-)> >>> Is any of this kind of work planned? The addition of those >>> MRegisterInfo functions has me curious... >> >> This is on our mid-term plan, which means we'll probably tackle it >> over >> the next year or so, but we don't have any concrete plans in the >> immediate >> future. If you are interested, this should be a pretty reasonable >> project >> that will give you a chance to become more familiar with various >> pieces of >> the early code generator. :) > > I have other higher priority tasks right now, but I think we'll want > to have this in sooner rather than later. If you have any pointers on > a good starting point it'd be mighty helpful. If I can get a grasp on > it I'll start incremental work in the background.It's really unclear how we will implement this. I haven't given it much thought because it's not yet important for us. If you have ideas, please share. :-)> > Probably the place to start would be opening a PR. Does "Support for > vreg subregs" capture the essence of the enhancement?Sure. Please add the relevant information from the thread to the bug though. Evan> > -- > Christopher Lamb > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Apr 23, 2007, at 8:22 PM, Evan Cheng wrote:> > On Apr 23, 2007, at 4:07 PM, Christopher Lamb wrote: > >> Thanks for the detailed response. >> >> On Apr 23, 2007, at 4:22 PM, Chris Lattner wrote: >> >>> Right. Evan is currently focusing on getting the late stages of >>> the code >>> generator (e.g. livevars) to be able to understand arbitrary machine >>> instrs in the face of physreg subregs. This lays the groundwork for >>> handling vreg subregs, but won't solve it directly. >> >> Is the work Evan doing a prerequisite for supporting vreg subregs? > > Sort of. vreg subregs work can start before I finish phyregs subregs > support. But unless there are no live-in registers nothing can > possibly work. > >> Is there a PR for the feature Evan is working on? > > You filed it. PR1306. :-)Ah! I didn't realize that the issue would have such far reaching consequences.>>>> Is any of this kind of work planned? The addition of those >>>> MRegisterInfo functions has me curious... >>> >>> This is on our mid-term plan, which means we'll probably tackle it >>> over >>> the next year or so, but we don't have any concrete plans in the >>> immediate >>> future. If you are interested, this should be a pretty reasonable >>> project >>> that will give you a chance to become more familiar with various >>> pieces of >>> the early code generator. :) >> >> I have other higher priority tasks right now, but I think we'll want >> to have this in sooner rather than later. If you have any pointers on >> a good starting point it'd be mighty helpful. If I can get a grasp on >> it I'll start incremental work in the background. > > It's really unclear how we will implement this. I haven't given it > much thought because it's not yet important for us. If you have > ideas, please share. :-)Chris had some suggestions about 2 posts back <http:// lists.cs.uiuc.edu/pipermail/llvmdev/2007-April/008834.html> He mentioned that the place where the constraint would need to be enforced was during the register rewriting pass. My first productive thoughts were to create a subclass of SDOperand (SDSubOperand) that Lowering could use to communicate the target specific subregister index. The other thought was to have something akin to "getSubRegisterForIndex()" in MRegisterInfo, which would return a sub register of the correct type at the specified index in a target dependent way. I'm not familiar with the register rewriting pass, so I'm not sure what data structures it needs/has access to. -- Christopher Lamb