<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Now that 2.5 is about to branch, I'd like to bring up one of Scott's <br>favorite topics: certain optimizers widen or narrow arithmetic, <br>without regard for whether the type is legal for the target. In his <br>specific case, instcombine is turning an i32 multiply into an i64 <br>multiply in order to eliminate a cast. This does simplify/reduce the <br>number of IR operations, but an i64 multiply is dramatically more <br>expensive than an i32 multiply on CellSPU.</div></blockquote><div><br></div><div>I basically agree with Scott on this: we shouldn't reintroduce types that</div><div>are illegal for the target after Legalize.</div><br><blockquote type="cite"><div>There are a couple of different ways to look at this. On the one <br>hand, I still strongly believe that codegen should be able to re- <br>narrow operations (and it does on his testcase on i386). However, <br>codegen is currently doing these optimizations on a per-basic block <br>basis, and we're not likely to have whole-function dags in the near <br>future, so there is an inherent limit to its power.<br><br>An earlier place to handle this is in codegen prepare, which is <br>global. However, the bad thing about this is that it would <br>effectively require duplicating all the type legalization code in CGP, <br>which is a pass we want to shrink, not grow. OTOH, the whole CGP pass <br>is really a hack around selection dags not being whole-function.<br><br>A third way to handle this is to add to target data a notion of <br>"native types". Instcombine could then be constrained to not do the <br>widening/narrowing transformations when the original type (i32 in this <br>case) was native but the destination type (i64) is non-native.<br><br>On the one hand, adding this to targetdata is simple and straight- <br>forward with well-defined semantics. OTOH, it is somewhat ugly that <br>IR canonicalization gets a bit more target-specific. </div></blockquote><br></div><div>IR after Legalize <b>is</b> target-specific (indeed that's Legalizer's job), so I don't see</div><div>why you should expect to treat it in a target-independent way. This seems</div><div>like the right fix to me. (I don't offhand see why the separation into legal and </div><div>illegal types that we already have isn't enough, but no doubt you're right.)</div><div><br></div><div><blockquote type="cite"><div>On the third <br>hand, instcombine already promotes indices of GEPs to match the <br>pointer size etc, so it wouldn't be too crazy for it to do this.<br><br>What do others think about this?<br><br>-Chris<br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></body></html>