<html><body bgcolor="#FFFFFF"><div>On Sep 22, 2007, at 10:36 AM, Christopher Lamb <<a href="mailto:christopher.lamb@gmail.com">christopher.lamb@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><div><div>On Sep 22, 2007, at 4:05 AM, Andreas Fredriksson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On 9/21/07, Christopher Lamb <<a href="mailto:christopher.lamb@gmail.com"><a href="mailto:christopher.lamb@gmail.com">christopher.lamb@gmail.com</a></a>> wrote:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ISel patterns are matched against DAGs before register allocation. So you</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">are correct that ISel patterns can't take into account register classes. The</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">register classes in the patterns are a selection constraint for the register</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">allocator if that instruction is chosen, not a constraint on choosing that</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">pattern.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Here's a possible way to proceed for now:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Define ADDA_32_dx without a pattern. Then in C++ pattern code for matching</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">address operands select add operations on addresses to ADDA_32_dx. This way</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">you know that the add your selecting is going to be used as an address and</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">you can safely tell the register allocator to put the value in an address</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">register.</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div></blockquote></div></div></blockquote><div><br class="webkit-block-placeholder"></div>This may work. But the mechanism is designed for load / store folding. What's described here means folding the address computation to a separate instruction. It's not clear how well this fits.<div><br class="webkit-block-placeholder"></div><div>I am going to suggest something shocking. :) Since you will end up writing a bunch of target specific code anyway, you might a well write a target specific pass that change generic instructions into data register variant ones when necessary.</div><div><br class="webkit-block-placeholder"></div><div>Evan<br><div><br><blockquote type="cite"><div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Thanks, I guess that makes sense. I might as well go ahead and create</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a general-purpose register class but then require that some operations</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">only target the data registers. For instance, multiplication is going</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to require data registers while indirect addressing requires address</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">registers.</div></blockquote><div><br class="khtml-block-placeholder"></div><div>I'd start with the most straight forward implementation that generates correct code. The register allocator currently doesn't handle these sorts of register allocation constraints in a sophisticated way, so I'd not worry about generating the most efficient code for now.</div><br><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Could something like the Uses and Defs constraints apply to whole</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">register classes as well? <br></div></blockquote><div><br class="khtml-block-placeholder"></div><div>I don't believe so. It's simply a list of physical registers AFAIK.</div><br><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">For instance, I assume the register</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">allocated is going to guarantee that EAX:EDX is not allocated around</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">an x86 integer division, and that the inputs end up in the right</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">registers. If those constraints "ripple up" through the function,</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">couldn't that be augmented to solve this problem as well so that</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">arithmetic would automatically select the data registers?</div> </blockquote></div><div><br class="khtml-block-placeholder"></div><div>Protecting EAX:EDX is relatively straight forward, it's having the inputs end up in the right registers that's tricky.</div><div><br class="khtml-block-placeholder"></div><div>I'm not an expert on the x86 back end, but my understanding of the register allocator is that it doesn't handle these sorts of cascades of constraints. The constraints are completely specified by the instruction that's selected, this means that a move instruction might need to be inserted to move a value between register classes or to specific registers. Though it's less than globally optimal, adding this sort of affinity propagation would likely add another complex dimension to determining optimal register allocation.</div><div><br class="khtml-block-placeholder"></div><div>Some options down the line would be to make more sophisticated patterns that select to instructions that operate on the right register classes from the start, or to have a custom machine instruction pass similar to x86's operand folding which could swap instructions (say from ADD_32_dx_dx to ADDA_32_dx) and perform the kind of "ripple up" that you described, eliminating unnecessary register to register copies along the way.</div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Christopher Lamb</div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span> </div><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu"><a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a></a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><br></div></blockquote></div></div></body></html>