<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 8, 2016, at 8:22 AM, Artur Pilipenko via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Sanjay,<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 19 Jul 2016, at 18:54, Sanjay Patel <<a href="mailto:spatel@rotateright.com" class="">spatel@rotateright.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">Hi Artur -<br class="">
<br class="">
</div>
I don't think there's any reason to limit the transform to sexts only; that's just the case that was apparent in
<a href="https://llvm.org/bugs/show_bug.cgi?id=20134" class="">https://llvm.org/bugs/show_bug.cgi?id=20134</a> , so I limited it to that pattern.<br class="">
<br class="">
</div>
It's probably worth noting that I'm currently fighting through casts of all kinds in IR (InstCombine) rather than the backend:<br class="">
</div>
</div>
</div>
</blockquote>
What is the current status of this work? Does it make sense to patch the existing code in X86ISelLowering in order to support looking through zext or the generic solution will be available soon?</div>
</div></div></blockquote><br class=""></div><div>As a side thought, this might be something best done in a CodeGenPrepare type position in the pipeline. The DAG is a little bit late because by that point you’ve lost some information (global information) and may not be able to eliminate all zexts/sexts accordingly. But instcombine may be a little bit early because it’ll hurt targets that prefer it the other way around. You could expand addressing mode stuff in CodeGenPrepare using knownbits or SCEV, maybe? We do something vaguely similar out of tree (but with the opposite goal, as our target only supports 32-bit offsets).</div><div><br class=""></div><div>—escha</div></body></html>