<div dir="ltr"><div>OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) is unecessary and the SelectVT is nto the right type (as it is called with incorrect parameter).<br><br></div>Here is a patch so it won't generate a loop. I ran make check and it doesn't look like anything is broken.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-07 11:36 GMT-07:00 Matt Arsenault <span dir="ltr"><<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
On Jul 5, 2014, at 7:14 PM, deadal nix <<a href="mailto:deadalnix@gmail.com">deadalnix@gmail.com</a>> wrote:<br>
<br>
> OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to tunc the result from i64 to i32 on 64 bits targets, if I understand correctly.<br>
><br>
> 2 questions:<br>
>  - Why not generating a selectcc node directly ? It avoid having to mess up with intermediate values.<br>
</div>Well first, that’s what it did originally and wasn’t what I was changing. selectcc might not be legal, and I’m not sure why it even exists.  I don’t see how it’s any harder to match select + setcc vs. selectcc, and selectcc just gives you another case to worry about.<br>


<div class=""><br>
<br>
>  - Why calling getSetCCResultType(VT) ? VT is not the type of a parameter of setcc, and this looks incorrect to me.<br>
</div>That’s what it did originally, and what I fixed. It now checks getSetCCResultType of the operand’s operand’s value type, the setcc’s operand</blockquote></div><br></div>