<div dir="ltr">Codegen is not the primary motivation here, so maybe I shouldn't have even mentioned that. However, you can find more context in:<br><a href="https://reviews.llvm.org/D26091">https://reviews.llvm.org/D26091</a><br><a href="https://reviews.llvm.org/D26096">https://reviews.llvm.org/D26096</a> (note how the optimizer can regress codegen)<br><br>The main concern is that we should choose a canonical form for IR that is easiest to reason about, and then we should transform all IR to that form. The backend shouldn't have to pattern match all of these variants - that's what IR is for.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 1:20 PM, Manuel Jacob <span dir="ltr"><<a href="mailto:me@manueljacob.de" target="_blank">me@manueljacob.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-11-07 20:01, Sanjay Patel via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FWIW, InstCombine doesn't canonicalize any of the first 3 options<br>
currently. Codegen suffers because of that (depending on the target machine<br>
and data types). Regardless of the IR choice, some backend fixes are needed.<br>
</blockquote>
<br></span>
I'm missing context here.  Can you describe in more detail how the IR choice affects the code generation?  In case the target has special integer min / max instructions, why is matching all three variants difficult?<span class="HOEnZb"><font color="#888888"><br>
<br>
-Manuel<br>
</font></span></blockquote></div><br></div>