<div class="gmail_quote">On Fri, Jan 30, 2009 at 9:59 AM, Villmow, Micah <span dir="ltr"><<a href="mailto:Micah.Villmow@amd.com">Micah.Villmow@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

The problem is linked to taking the address of the stack variable and<br>
passing it as a pointer to another function.</blockquote><div><br>This is a common optimization since the addressing is a (simple, propagated) base+offset and doesn't require a new stack spill.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

So, my questions are:<br>
1) Is there anything special I should be doing to handle a<br>
FrameIndexSDNode being passed into LowerCALL?</blockquote><div> <br>No. The CellSPU backend doesn't do anything special in this regard. It just sees a MVT::i32 pointer.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

2) If not, Where can I look that might show some light on what I'm doing<br>
wrong in tablegen/ISelLowering?</blockquote><div><br>You might need to add some code to your ISelDAGToDAG source during instruction selection to catch FrameIndex nodes and generate the instruction sequence that creates the proper base+offset pointer. What you're likely seeing is a FrameIndex that's used multiple times ("<multiple use>" when you dump the DAG) and is now higher in the DAG as a sole node.<br>
<br>I'm surprised, however, that you haven't yet seen a "Cannot select ..." assert.<br><br><br>-scooter<br></div></div><br>