<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Yes, same deal. Everything between lsr and the isel phase of the dag machinery would be fixed by an intrinsic. It would also eliminate the need for "complex pattern" complexity in the targets.<br><br><div>-Chris</div></div><div><br>On Apr 26, 2014, at 3:15 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 26, 2014 at 2:41 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 class="">On Apr 25, 2014, at 7:53 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
<div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>With my current prototype, I see up to 30% speed up on small kernels.</div>
</blockquote></div><div class="gmail_extra"><br></div>Cool.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My only concern are the cases where not doing the scale requires more instructions. In particular, I have seen a lot of performance problems in the past[1] which stemmed essentially from using lea to do address computations so that the addressing mode operand was simpler. Just want to make sure the LSR and other users of this will be sufficiently conservative.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">[1]: So fun story here. The fact that LLVM so aggressively forms complex addressing modes may explain why this used to be such a big problem for me. It would use every single part of the addressing mode in structuring the loop body, and then during instruction selection we would fail in a large number of cases to match that as an actual addressing mode. I spent a bunch of time teaching the instruction selection layer for x86 to re-constitute every addressing mode it could in order to fix this. This may even become relevant, because while I *tried* to only do these heroics for cases that were strictly better (ie, fewer instructions total), I could have messed it up, and we might re-form complex addressing modes even when unnecessary.</div>
</div></blockquote><br></div></div><div>The "right" answer here is to introduce a new llvm intrinsic to represent addressing modes. It is ridiculous that LSR and CGP generate LLVM "very carefully" with the expectation that selection dag will be able to reconstitute it... and that nothing between them will mess things up.</div>
</div></blockquote><div><br></div><div>Well, if this is a problem, it isn't the problem I hit. ;] I dunno that we need this at this point as i've not seen any problems with information loss between LSR and the DAG.</div>
<div><br></div><div>The problem I hit was the *DAG* destroying the information because it is represented as arbitrary math in the DAG and we have a bunch of DAG combines for math. If you want to make the problem I observed better, the way to do so is to introduce an addressing mode DAG node (or kill off the DAG completely).</div>
</div></div></div>
</div></blockquote></body></html>