<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 10:08 PM, David Majnemer via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">IMO, canonicalization is driven by a few priorities:<div>- How easy is it for the rest of the optimizer to reason about the IR<br><div>- How easy is it to lower the IR to "The Right Thing (TM)"</div><div><br></div><div>I think it is hard to know which is best without resorting to a case-by-case analysis, mostly because of stuff like ComputeKnownBits.</div><div><br></div><div>Outside a few special cases, ComputeKnownBits isn't very smart when it comes to select: it just takes the intersection of the two possibilities. This can lose quite a bit of information.</div><div><br></div><div>I'd feel a lot better about always canonicalizing to select if the backends are strengthened to lower those selects to something good (without relying on CMOV, etc.) and if ComputeKnownBits dealt with select better.</div></div></div></blockquote><div><br></div><div>I don't see how ComputeKnownBits can be improved here. Because the return value can be 0 or -1 then any bit can be 0 or 1, which is without information, but optimal.</div><div>This is a fundamental limitation of the ComputeKnownBits representation.</div><div><br></div><div>Note we could drastically improve it by having two set of ComputeKnownBits:</div><div>- one for when the MSB is 0</div><div>- one for when the MSB is 1</div><div><br></div><div>But that is an other discussion I guess.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</div></div>