[PATCH] When canonicalizing gep indices, prefer zext when possible

[Chandler Carruth]

Just commenting on the high-level question.

On Fri, Feb 13, 2015 at 2:10 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

> 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.


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.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150213/f70ba441/attachment.html>