<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 25, 2012, at 9:14 AM, Bob Wilson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 24, 2012, at 11:41 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 24, 2012 at 11:22 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Apr 24, 2012, at 3:10 PM, Lang Hames wrote:</div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Chandler,</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">
<div>I'm not sure what you mean by "the right size" here? the vmull_n_* intrinsic parameters are always half the width of its result, so they'll never be "the right size" by that measure. I'll try deferring the simplification though - that might be a win.</div>
</div></div></blockquote><div><br></div><div>No such luck - deferring simplification of the ext instructions causes this to miss a lot of opportunities.</div><div> </div><div>Will be OOO for the next hour or so. Hopefully I'll catch you when I get back.</div>
</div></div></blockquote><br></div></div></div><div>Hi Lang,</div><div><br></div><div>I think the best thing to do is to revert this patch until we can work out a solution that works. We really don't like instcombine code that "creates some IR, then sees if it can simplify, if not remove it", as we talked about these evening.</div>
</div></blockquote><div><br></div><div>Hey,</div><div><br></div><div>Just as an update, Lang already reverted the patch.</div><div><br></div><div>He and I looked at a bunch of different options, and I think sense all this intrinsic is, is a multiply, he's going to look into representing it using the normal vector multiply in the IR, and pattern matching it back to the instruction in the backend.</div>
<div><br></div><div>If that doesn't work for some reason (say, for example, there is something that necessitates the *exact* lowering of this intrinsic to the instruction), we talked about how to detect opportunities for simplifications, and do a more instcombine-y transform.</div></div></div></blockquote><br></div><div>I already replied to Lang's initial posting of the patch, but there is a problem with representing it as a normal vector multiply. We used to do it that way and had to give up and use intrinsics because we saw important cases where the sext/zext got moved to a different basic block, which caused us to fail to select the desired instruction.</div></div></blockquote><div><br></div>I vaguely remember this. Do you remember why the multiply isn't moved together with the sext / zext?</div><div><br></div><div>Evan</div><div><br><blockquote type="cite">
_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br></blockquote></div><br></body></html>