<div dir="ltr"><div class="gmail_extra">Just commenting on the high-level question.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 2:10 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm of the opinion that zext should be more canonical than sext in this case because zext's are simpler to analyze.  I can't immediately see why this canonicalization wouldn't be preferable except for bugs/deficiencies in other combines.</blockquote></div><br>Well, one potential reason is that it means that we can't look for a single form of extension in the operands. But I don't think that needs to motivate this.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I think phrasing this as a canonicalization of GEP indices is the thing that is wrong. Instead, let's just look at (sext i32 %x to i64). Why not canonicalize a sext of a known-positive value to a zext? Regardless of whether it is a GEP consuming it or not, if the above logic for preferring zext over sext holds, we should always do that, and we shouldn't try to handle this when dealing with GEPs, we should just have it form the sext and let instcombine hack on that instruction. In fact, I thought we already did this... But I haven't checked.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The only reason I can think of to not canonicalize sext -> zext in general would be if for some reason it made patterns matching extensions more complex (due to having to handle a mixture of sext and zext). We should look at that, but I'm not too worried. If that happens to be a problem, we could always do sext -> zext in CGP. I agree that at some point we should definitely remove all sext's of known-positive values.</div></div>