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
On Tue, 24 Apr 2007, Christopher Lamb wrote:>>> 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. :-)hehe, I've been thinking about this for years :)> 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.Yes, we need those. I think these are the major pieces needed. These are all relatively small and independent pieces, so we can tackle these one at a time. 1. As you say, we need MRegisterInfo::getSubRegisterForIndex that, given a preg/subreg# pair, returns a preg. 2. We need tblgen syntax/registerinfoemitter support to generate tables for #1. 3. Register MachineOperands need a subregister number. We should probably use 0 to denote "no subreg". 4. The DAG scheduler pass (which creates machine instrs from dag nodes) currently thinks of register operands as simple unsigned's for vreg #'s. This needs to be extended to be vreg+subreg pairs (see 'CreateVirtualRegisters'). 5. We need to decide how to represent subregs in the DAG. Your SDSubOperand idea is fine, but I don't think it needs to be an actual new subclass of SDOperand. Instead, it could just be a binary SDNode, where the LHS is the register input and the RHS is a TargetConstant specifying the subreg#. 6. [optional] We would like syntax to create these things for writting patterns in the .td file instead of requiring custom matching code. 7. The register allocator needs to rewrite subreg references using #1. This should be very simple. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Apr 24, 2007, at 12:01 PM, Chris Lattner wrote:> Yes, we need those. I think these are the major pieces needed. > These are > all relatively small and independent pieces, so we can tackle these > one at > a time.<snip>> 4. The DAG scheduler pass (which creates machine instrs from dag > nodes) > currently thinks of register operands as simple unsigned's for > vreg > #'s. This needs to be extended to be vreg+subreg pairs (see > 'CreateVirtualRegisters'). > 5. We need to decide how to represent subregs in the DAG. Your > SDSubOperand idea is fine, but I don't think it needs to be an > actual > new subclass of SDOperand. Instead, it could just be a binary > SDNode, > where the LHS is the register input and the RHS is a > TargetConstant > specifying the subreg#. > 6. [optional] We would like syntax to create these things for writting > patterns in the .td file instead of requiring custom matching > code. > 7. The register allocator needs to rewrite subreg references using > #1. This should be very simple.For 5 I am currently creating new binary SDNodes for 'from_subreg' and 'to_subreg' in ISD, is this in line with your thinking for the design Chris? The issue I ran into is that you essentially need subreg insert and extract. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070606/08b71094/attachment.html>