Ok, thanks. <br><br>Even still though I would expect -instcombine (run after lsr) would do this cleanup?<br><br><div class="gmail_quote">On Fri, Oct 19, 2012 at 2:41 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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"><br><div><div class="im"><div>On Oct 19, 2012, at 2:34 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> wrote:</div>
<br><blockquote type="cite">That solves the issue but it seems odd to me that instcombine doesn't take care of it?<br></blockquote><div><br></div></div><div>LSR is part of the backend. It's lowering the IR for a specific target. It seems to think those redundant operations are good for reducing register pressure, but doesn't actually have much knowledge about register pressure. At this point, we won't do any more IR level "cleanup" since that tends to undo lowering. The Machine IR passes will do some careful cleanup.</div>
<div><br></div><div>-Andy</div><div><div class="h5"><br><blockquote type="cite">So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant operations, should it not clean itself up? Or am I mistaken?<br>

<br><div class="gmail_quote">On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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><br><div><div>On Oct 17, 2012, at 1:22 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> wrote:</div><br><blockquote type="cite">

I'm curious why I am seeing this: <br><br>  <b>%uglygep18.sum = add i32 %lsr_iv8, %tmp45</b><br>  %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum<br>  %scevgep1920 = bitcast i8* %scevgep19 to i16*<br>
  %tmp78 = load i16* %scevgep1920, align 2<br>

 <b> %uglygep14.sum = add i32 %lsr_iv8, %tmp45</b><br>  %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum<br>  %scevgep1516 = bitcast i8* %scevgep15 to i16*<br>  %tmp79 = load i16* %scevgep1516, align 2<br>  %conv93.i.i = sext i16 %tmp79 to i32<br>


  <b>%uglygep.sum = add i32 %lsr_iv8, %tmp45</b><br>  %scevgep11 = getelementptr i8* %sysBits_010, i32 %uglygep_sum<br><br>You can see here that "add i32 %lsr_iv8, %tmp45" is done multiple times, appearing that there are two redundant add operations that are not needed yet are generated?<br>

</blockquote></div><br></div></div><div>That's LSR, as you can see from the variable names ;) It might think that load(Base + Index) is a legal addressing mode for your target. -disable-lsr might be the right thing for you anyway.</div>

<div><br></div><div>Incidentally, MachineCSE could clean this up if it doesn't get folded into the address, but like LSR, it tries hard not to increase register pressure.</div><div><br></div><div>-Andy</div></div>
</blockquote></div><br>
</blockquote></div></div></div><br></div></blockquote></div><br>