<div class="gmail_quote">2009/6/17 Török Edwin <span dir="ltr"><<a href="mailto:edwintorok@gmail.com">edwintorok@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi,<br>
<br>
I noticed that umax (zext t1 %X to %t0, zext t1 %Y to %t0) isn't folded,<br>
the attached patch folds this into:<br>
umax (zext t1 %X to %t0, zext t1 %Y to %t0).<br>
<br>
It also folds umax (sext t1 %X to %t0, sext t1 %Y to %t0) ->  sext t1<br>
(umax (%X, %Y)) to %t0.<br>
</blockquote><div><br>Unless I'm mistaken, we deliberately push them the other way so that we can eliminate ext(constant) inside of the umax. Also, since umax can take multiple operands we get to canonicalize "umax(zext(umax(a, b)), c)" into "umax(zext(a), zext(b), c)".<br>

<br>There's an ordering defined in ScalarEvolutionExpressions.h (scConstant to scUnknown) which should match the inside-to-outside order that we want SCEVs to have when canonicalizing.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


zext is very often encountered in SCEV expressions on x86-64, since<br>
pointer indexes for GEP are i64.<br>
<br>
Thoughts?</blockquote><div><br>This is a real problem that deserves a fix, I'm just not sure I like the one proposed. How hard would it be to add logic to detect this case to the ScalarEvolutionExpander? Just look inside the umax and see whether all its operands contains the same zext/sext/trunc and hoist it then.<br>

<br>Nick<br><br></div></div>